From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 289377EE5C for ; Tue, 6 May 2014 12:42:16 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.192.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.192.49 as permitted sender) identity=mailfrom; client-ip=209.85.192.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f49.google.com) identity=helo; client-ip=209.85.192.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-qg0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkBAAi8aFPRVcAxlWdsb2JhbABZg1VYgmeqHY5diHuBFAgWDgEBAQEHDQkJEiqCJQEBBAEjHQEbEgsBAwELBgUEBw0NHQICIgERAQUBChIGExICiBgBAwkIDZt5jBFRgw2aMQoZJwMKZIVgEQEFDI5CBAeCdIFLBIRaA5Bjg3eBPIlEhgoYKYJwgXY7 X-IPAS-Result: AlkBAAi8aFPRVcAxlWdsb2JhbABZg1VYgmeqHY5diHuBFAgWDgEBAQEHDQkJEiqCJQEBBAEjHQEbEgsBAwELBgUEBw0NHQICIgERAQUBChIGExICiBgBAwkIDZt5jBFRgw2aMQoZJwMKZIVgEQEFDI5CBAeCdIFLBIRaA5Bjg3eBPIlEhgoYKYJwgXY7 X-IronPort-AV: E=Sophos;i="4.97,996,1389740400"; d="scan'208";a="60762476" Received: from mail-qg0-f49.google.com ([209.85.192.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 May 2014 12:42:06 +0200 Received: by mail-qg0-f49.google.com with SMTP id a108so2497653qge.36 for ; Tue, 06 May 2014 03:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9c1whzu7KsNLxxyTQgV10i+Nbx+3LM5iptkcQ/C1DHo=; b=bsIkHUK1SRbghtIZI7bNHnsxrorcv0KryQge0b/fhJq5Hv7enGqbjipc42NpP41rDr fkO6+TX52rPvr6fYJRjNzpS4tsZ+iSfReeS70v5AQxPEhSy2y30uZ6+QDspQHA1xcEVV SzGA0FbSsYl8erpL/+/JeHRUzAQtIwywnWVtqHTdFCuiOrXk3THoZTyQ/qbWrtAihctJ eQteYnmFHkGGqkMeNsSXEpIPaaIwRnspKioIIZ5KFeYi1HiFCT2bssxpZ3+8zKOL8PnT yOifbrguNJuTPbPUZFhSbopOjarNdQgH70XKlTF/2YC1hwqQ9xp1lVpBZGuyjeox0Rsx 9a0A== MIME-Version: 1.0 X-Received: by 10.229.220.197 with SMTP id hz5mr48751259qcb.9.1399372926073; Tue, 06 May 2014 03:42:06 -0700 (PDT) Received: by 10.140.38.147 with HTTP; Tue, 6 May 2014 03:42:05 -0700 (PDT) Received: by 10.140.38.147 with HTTP; Tue, 6 May 2014 03:42:05 -0700 (PDT) In-Reply-To: <53686514.8070200@frisch.fr> References: <6232dace806569a16f7fbfaa1689ef42@whitequark.org> <53686514.8070200@frisch.fr> Date: Tue, 6 May 2014 12:42:05 +0200 Message-ID: From: Malcolm Matalka To: Alain Frisch Cc: caml-list , Peter Zotov , "wg-camlp4@lists.ocaml.org" Content-Type: multipart/alternative; boundary=001a11346f6a2b01dc04f8b8e6fa Subject: Re: [Caml-list] [ANN] ppx_protobuf --001a11346f6a2b01dc04f8b8e6fa Content-Type: text/plain; charset=UTF-8 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" : > 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 > --001a11346f6a2b01dc04f8b8e6fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

Den 6 maj 2014 06:29 skrev "Alain Frisch&qu= ot; <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 point= s!

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 cons= ensus.

For instance, ppx_protobuf relies on attributes with quite generic names su= ch as @default or @key, that might also be useful to other tools. =C2=A0It = 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. =C2=A0This is good, since attributes are not designed to be= necessarily targeted to only one specific tool. =C2=A0But in some cases, o= ne might want to use a different @default attribute for different tools. = =C2=A0What about supporting both a short form @default and a more qualified= one @protobuf.default? =C2=A0This 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, b= ut it seems that it might be more logical to attach them to the field direc= tly (do you confirm?):

=C2=A0 type defaults =3D {
=C2=A0 =C2=A0 =C2=A0results [@key 1] [@default 10]: int;
=C2=A0 } [@@protobuf]

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

=C2=A0 type defaults =3D {
=C2=A0 =C2=A0 =C2=A0results : int [@key 1] [@default 10];
=C2=A0 } [@@protobuf]

?

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


-- Alain

--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs
--001a11346f6a2b01dc04f8b8e6fa--