Re: [Caml-list] [ANN] ppx_protobuf

[Alain Frisch <alain@frisch.fr>]

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