I think making the application of a ppx look more like a functor application solves the name spacing issue for the most part.

Den 6 maj 2014 06:29 skrev "Alain Frisch" <alain@frisch.fr>:
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

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs