Re: [Caml-list] [ANN] ppx_protobuf

[Peter Zotov <whitequark@whitequark.org>]

On 2014-05-06 08:29, Alain Frisch wrote:
> 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!

Thanks!

> 
> 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.
> 
> (a suggestion to recognize both [@x] and [@protobuf.x])

I have designed ppx_protobuf's usage of attributes with exactly this in 
mind;
[@default] especially would be useful for a wide range of type-driven 
code
generators.

I actually intended to release it with the support for namespaced 
attribute
variants ([@protobuf.key]), it has simply been forgotten. I'll include 
it
in the next release.

> 
> 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.

The issue here is that I want to support "immediate tuples" (i.e.
"field : int * int", or, more importantly, "A of int * int", which
are semantically equivalent to and represented as a Protobuf message.
As such, I felt it would be only consistent to have the same syntax
for specifying options on an immediate tuple of several elements:

   results : int [@encoding zigzag] * int [@encoding bits32]

and for specifying options on a "tuple of one element":

   results : int [@encoding zigzag]

I'm not entirely happy with this scheme; the way it gives rise to the 
message
structure is at best confusing, as adding or removing a tuple element 
can
add or remove nesting and thus break protocol compatibility. In 
addition,
the [@key] attribute on, for example, a field itself would currently be 
ignored.
While this behavior can be fixed for the most common misplacements, I 
feel like
it's a drawback intrinsic to the extension points mechanism: misplaced 
or misnamed
attributes are going to be silently ignored.

Do you have any ideas for a solution? I have toyed with an idea of
a "verifier extension" which would ascertain the lack of attributes 
after
all the rewriter passes have presumably removed the attributes known
to them, but it wouldn't work  with generic attributes like [@default] 
that
must be shared between extensions.

> 
> 
> -- Alain

-- 
Peter Zotov
sip:whitequark@sipnet.ru