From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 613297F726
	for <caml-list@sympa.inria.fr>; Tue,  6 May 2014 06:29:07 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=pra; client-ip=80.12.242.124;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=mailfrom; client-ip=80.12.242.124;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@smtp.smtpout.orange.fr) identity=helo;
  client-ip=80.12.242.124;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="alain@frisch.fr";
  x-sender="postmaster@smtp.smtpout.orange.fr";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgBAB1kaFNQDPJ8lGdsb2JhbABZyQSBMQ4BAQEBBwsLCRIqgiUBAQU4QBELDgoJFg8JAwIBAgFFBgEMCAEBEIgxzXMXjlmEPwEDlUCDd4ZkhBuLLw
X-IPAS-Result: AkgBAB1kaFNQDPJ8lGdsb2JhbABZyQSBMQ4BAQEBBwsLCRIqgiUBAQU4QBELDgoJFg8JAwIBAgFFBgEMCAEBEIgxzXMXjlmEPwEDlUCDd4ZkhBuLLw
X-IronPort-AV: E=Sophos;i="4.97,994,1389740400"; 
   d="scan'208";a="72268745"
Received: from smtp02.smtpout.orange.fr (HELO smtp.smtpout.orange.fr) ([80.12.242.124])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 06 May 2014 06:29:07 +0200
Received: from [192.168.1.27] ([81.249.123.176])
	by mwinf5d55 with ME
	id yUV41n0053oTwKV03UV5Jm; Tue, 06 May 2014 06:29:06 +0200
X-ME-Helo: [192.168.1.27]
X-ME-Auth: ZnJpc2NoLmFsYWluQHdhbmFkb28uZnI=
X-ME-Date: Tue, 06 May 2014 06:29:06 +0200
X-ME-IP: 81.249.123.176
Message-ID: <53686514.8070200@frisch.fr>
Date: Tue, 06 May 2014 06:29:08 +0200
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Peter Zotov <whitequark@whitequark.org>, 
 caml-list <caml-list@inria.fr>,
 "wg-camlp4@lists.ocaml.org" <wg-camlp4@lists.ocaml.org>
References: <6232dace806569a16f7fbfaa1689ef42@whitequark.org>
In-Reply-To: <6232dace806569a16f7fbfaa1689ef42@whitequark.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] [ANN] ppx_protobuf

On 5/2/2014 4:29 PM, Peter Zotov wrote:
> I have just released the first version of ppx_protobuf, a complete
> Protocol Buffers implementation.

This is a very cool project, and a good first public use of extension 
points!

An aspect of attributes that is not fully settled is how to use 
namespacing in order to ensure that multiple tools interact nicely.
This topic will hopefully be explored by the community to reach a good 
consensus.

For instance, ppx_protobuf relies on attributes with quite generic names 
such as @default or @key, that might also be useful to other tools.  It 
might very well be the case that the same @default attribute (with the 
same value) would actually be useful to both ppx_protobuf and another 
deriving-like extension.  This is good, since attributes are not 
designed to be necessarily targeted to only one specific tool.  But in 
some cases, one might want to use a different @default attribute for 
different tools.  What about supporting both a short form @default and a 
more qualified one @protobuf.default?  This should support both situations.

Another point: for record fields, you interpret attributes at the 
toplevel of their type. I did not look precisely at the semantics of 
ppx_protobuf, but it seems that it might be more logical to attach them 
to the field directly (do you confirm?):

   type defaults = {
      results [@key 1] [@default 10]: int;
   } [@@protobuf]

I understand that this form is syntactically "more intrusive" in the 
non-decorated type definition.  Is it the reason to use:

   type defaults = {
      results : int [@key 1] [@default 10];
   } [@@protobuf]

?

I don't see anything wrong with doing so, although it might be worth 
supporting both forms.


-- Alain