[wg-camlp4] Request for feedback

[Gabriel Scherer]

The translation of
   KW%id[@id expr]..[@id expr] REST
into
  [%id KW REST] [@id expr]..[@id expr]
is surprising to me. I would instead have expected it to translate into
  [%id (KW REST)[@id expr]..[@id expr] ]
(the extensions would have precedence over attributes, so that
localized extension handlers only rewriting what is inside the [%id
EXPR] can see the attributes and react to them)

Among the options you highlight, my own current preference goes for (3).

I think the question is: how much do we need for the "easy cases" of
current camlp4 users to switch to this style, and not the style of
"overloading valid code semantics" that is currently used by, say,
ppx_monad, and I think is the wrong way to go on the long term?

If having a convenient syntax as discussed here is not necessary to do
the switch, maybe that's enough. But if it is necessary, I think it
should be agreed upon right away, to be sure that the "good solutions"
will not, when studied in the future, require changes to what you will
implement short-term.

On Thu, Mar 21, 2013 at 11:15 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>> 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.
>>
>
> I'm basically fine with 2, 3 or 4. I would also be fine with:
>
>   1.5. Completely get rid of the "prefix" syntax for extensions but
>        keep it for attributes.
>
> It might be best to go with 2 for now since, as you suggested, it will be
> much easier to add syntactic sugar later than to remove it.