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 5BD347F726 for ; Tue, 6 May 2014 09:33:54 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.213; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.213; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.213; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAH+PaFPB/BfVnGdsb2JhbABQCcV4gxGBMA4BAQEBAQgUCTyCJQEBBAE4QAEFCwsOCgkWDwkDAgECAUUGDQEHAQEXiB4MzXkXjW8IWweEPwEDmTeGZIQbiy8 X-IPAS-Result: AhkBAH+PaFPB/BfVnGdsb2JhbABQCcV4gxGBMA4BAQEBAQgUCTyCJQEBBAE4QAEFCwsOCgkWDwkDAgECAUUGDQEHAQEXiB4MzXkXjW8IWweEPwEDmTeGZIQbiy8 X-IronPort-AV: E=Sophos;i="4.97,995,1389740400"; d="scan'208";a="60730355" Received: from msa04.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.213]) by mail3-smtp-sop.national.inria.fr with ESMTP; 06 May 2014 09:33:53 +0200 Received: from [192.168.1.133] ([92.151.12.96]) by mwinf5d31 with ME id yXZk1n00F24LMec03XZnmT; Tue, 06 May 2014 09:33:53 +0200 X-ME-Helo: [192.168.1.133] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Tue, 06 May 2014 09:33:53 +0200 X-ME-IP: 92.151.12.96 Message-ID: <53689057.5010802@frisch.fr> Date: Tue, 06 May 2014 09:33:43 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Peter Zotov CC: caml-list , wg-camlp4@lists.ocaml.org References: <6232dace806569a16f7fbfaa1689ef42@whitequark.org> <53686514.8070200@frisch.fr> <5c5c8af234151e7fdc529a63ce305dab@whitequark.org> In-Reply-To: <5c5c8af234151e7fdc529a63ce305dab@whitequark.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] [ANN] ppx_protobuf On 05/06/2014 06:59 AM, Peter Zotov wrote: > 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. Indeed. > 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. I'm not convinced by the idea of checking the absence of attributes after -ppx rewriters are applied. You mention one reason (generic attributes, which shouldn't be discarded by any specific -ppx), but there are others: - Even non-generic attributes might be better left in the Parsetree sent to OCaml, so that they appear in particular in the dumped typedtree (.cmt/.cmti), which could be useful for further processing (e.g. a version of ocamldoc based on .cmti files). - Attributes are not only designed to support -ppx rewriters. They can also be used by tools which inspect compiled .cmt/.cmti/.cmi files, or stand-alone tools which work on source files but are not used as preprocessors. - There is also the case of "optional" -ppx rewriters (e.g. a code instrumentation tool which could be applied or not). An "attribute checker" (either integrated in a generic style-checking tool such as Mascot or as a stand-alone tool, or maybe even as an "identity" -ppx so that it is always included in the compilation chain) would need some way to know which attributes are allowed and in which context (it's fair to let each tool check the advanced conditions on the payload and constraints such as nesting conditions). For instance, each tool could come with a small text file describing the attributes it recognizes (and in which contexts), maybe also with a rough description of admissible payloads and -- why not -- some succinct documentation about the attribute. This information could be useful not only for the attribute checker, but potentially by other tools as well (e.g. an IDE). -- Alain