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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 02ADC7F726 for ; Tue, 6 May 2014 06:59:51 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AolyAPZqaFOwOmd9/2dsb2JhbABZrmsBAQEBAQEFAYEomGWBMXSCJQEBBAE4Aj8QBAcYLiwrBhMIDAeIHgzNaReFVoM+hDEqYweEPwEDigKLPo52h3mDOTg X-IPAS-Result: AolyAPZqaFOwOmd9/2dsb2JhbABZrmsBAQEBAQEFAYEomGWBMXSCJQEBBAE4Aj8QBAcYLiwrBhMIDAeIHgzNaReFVoM+hDEqYweEPwEDigKLPo52h3mDOTg X-Spam-Status: Yes X-IronPort-AV: E=Sophos;i="4.97,994,1389740400"; d="scan'208";a="72270631" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP; 06 May 2014 06:59:49 +0200 Received: by mail.whitequark.org (Postfix, from userid 33) id 790134D72B; Tue, 6 May 2014 04:59:48 +0000 (UTC) To: Alain Frisch X-PHP-Originating-Script: 1000:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 06 May 2014 08:59:48 +0400 From: Peter Zotov Cc: caml-list , wg-camlp4@lists.ocaml.org In-Reply-To: <53686514.8070200@frisch.fr> References: <6232dace806569a16f7fbfaa1689ef42@whitequark.org> <53686514.8070200@frisch.fr> Message-ID: <5c5c8af234151e7fdc529a63ce305dab@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.0.0 Subject: Re: [Caml-list] [ANN] ppx_protobuf 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