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

[Hongbo Zhang]

I would be very happy to see some killer applications written using
extension_point to be convinced that extension_point is awesome for
metaprogramming.

Currently, I am building a c code generation framework and continuing
jaked's work on ocamljs on top of Fan. I really learned a lot during the
development and did fix some bad designs of Fan, such a way of learning may
also benefit the design of extension_point.



On Thu, May 2, 2013 at 3:33 AM, Alain Frisch <alain.frisch at lexifi.com>wrote:

> 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
>
> ______________________________**_________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/**listinfo/wg-camlp4<http://lists.ocaml.org/listinfo/wg-camlp4>
>



-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130502/0c3ec5d1/attachment.html>