[wg-camlp4] [Caml-list] [ANN] ppx_protobuf
Peter Zotov
whitequark at whitequark.org
Tue May 6 05:59:48 BST 2014
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 at sipnet.ru
More information about the wg-camlp4
mailing list