[wg-camlp4] Request for feedback

Alain Frisch alain.frisch at lexifi.com
Thu Mar 21 09:15:45 GMT 2013

On 03/15/2013 04:16 PM, Gabriel Scherer wrote:
> I suspect we could get some value, for example, of
>    let at nowarn [x;y;z] = List.map normalize [x;y;z]
> (More generally I've been thinking about compiler pragmas, and those
> often don't need arguments.)
> I think the answer is yes, but I don't quite remember: if let[@foo
> bar] .. = ... in .. is accepted, do we also allow let[%foo bar] ... in
> ... as a shortcut for [%foo bar (let .. in ...)]?

No, currently let[%foo bar] ... in ... is not allowed.

I think we should move forward and make a decision concerning the 
alternative syntax for attributes and extension nodes on opening 
delimiters and keywords.  As a reminder, the current version in the SVN 
supports the following sugar for an EXPRESSION which starts with a 
keyword or delimiter KW (EXPRESSION == KW REST):


   KW[@id expr]...[@id expr] REST
   EXPRESSION[@id expr]...[@id expr]

Extension node:

   KW%id REST

Attributes on extension node:

   KW%id[@id expr]...[@id expr] REST
   [%id EXPRESSION][@id expr]...[@id expr]

where KW can stand for:

  let module
  let open

I propose to choose between one of the following:

  1. Continue with the current situation.

  2. Completely get rid of this alternative "prefix" syntax for 
attributes and extension points.  This only affect parser.mly and can 
easily be discussed again and added later.  This would reduce the 
changes to the concrete grammar (and would thus simplify supporting 
attributes and extension points in Camlp4)

  3. Keep the syntax, but only for real keywords, not opening delimiters 
( [ [| { and {<.

  4. Do something special for "let" (it has been argued that for other 
constructions, the normal syntax of extension point does not add too 
much overhead); to be detailed.

Note, even if we go with 2, we can still write:

  let (x, y) [@lwt] = ... in

i.e. use (a postfix) attribute on the (first) pattern of the binding.

I'm now slightly in favor of 2, neutral between 1 and 3, and slightly 
against 4.

Please share your opinion (and feel free to propose something else)!


More information about the wg-camlp4 mailing list