[wg-camlp4] Negative field report: extension points unsuited for (matches p when e)

[Alain Frisch]

Hi Gabriel,

Thanks for the feedback.

I think it is to be understood that -ppx and extension_point do not 
target "syntax extension in the small", as you say.  I'd go as far as to 
say that they are not really about "syntax extension", since the whole 
idea is not to touch the concrete syntax.  Compared to Camlp4, Camlp5 or 
Fan, indeed, we loose the ability to provide nice little convenient 
syntactic shortcuts, and for this reason, there will still be some space 
for those tools, for people actually interested in changing the concrete 
syntax (and accepting the price to pay for it, in particular having to 
adapt their editor mode).  Luckily, I believe that most of the 
wide-spread current uses of Camlp4 don't fall in this category where the 
syntactic compactness is the ultimate goal:

   - code generation driven by type declaration;

   - code instrumentation (à la Bisect);

   - macro/conditional compilation;

   - monadic syntax (--> e.g. suggested syntax for lwt: let%W p = ...)

   - custom pattern matching (bitstring, ulex).


As a side note, I've recently changed the syntactic category accepted as 
arguments of attributes/extensions from expressions to structures, which 
are strictly more general (an expression is also syntactically a valid 
structure item, and thus a structure, in itself).

It was also discussed, some time ago, to merge the syntactic categories 
of expressions and patterns (patterns are already "almost" a 
sub-category of expressions).  This could have helped in your case (not 
for the "when" part, though).

On 05/01/2013 04:44 PM, Gabriel Scherer wrote:
> For the purpose of experimentation, I still decided to do an
> implementation based on a horrible hack, namely using (the new syntax
> for) string literals that had been presented as a way to get "foreign
> language quotations" in this context, with the syntax [%matches {|
> <patt> when <expr> |}]. I believe this course of action should be
> discouraged; in particular, there is no proper error handling. It
> seems that deploying extensions based on this principle would
> constitute a regression from the current Camlp4 situation.


I know that you're allergic to this approach, but you could also have 
adopted the following syntax:

{matches|<patt>|}
{matches|<patt> when <expr>|}

i.e. reusing syntax for an otherwise valid expression (a string 
literal).  Indeed, the "marker" for new string literals is kept in the 
Parsetree.  And those string literals have the nice property that a 
position within the string literal can be mapped to a location in the 
source code (just shift by N+2 characters, where N is the length of the 
string market, 7 in that case).  Indeed, no character within the string 
literal is interpreted in a special way (no escaping or special 
character) and whitespaces are not allowed around the marker.  This 
would support exact error reporting.

Leo has proposed to provide a combined syntax for extension node + 
quotation. This would give a cleaner way, of course, compared to 
piggy-backing valid syntax.



Alain