[wg-camlp4] Structured comments, shallow embeddings and deep quasiquotations

[Philippe Veber]

Hi all,

I find Jeremy's proposal very convincing : it's very clean and seems to fit
with a lot of situations. One of its main strengths is that the functions
called at ppx time are only passed the annotated expression/item (maybe
that was proposed before, but I did not see it). I think this is a major
improvement from the current ppx option, which deals with the whole parsed
tree each time, and makes extension composition a lot more difficult to
grasp. Having extensions mapped to functions (like deriving or perform) is
also a very nice way to prevent conflicting extensions.

So as a potential user, I'd buy it without hesitation, but maybe there is
some limitation I overlooked?

Another great thing I think is that it may also simplify the build process
: writing an extension is as easy as providing a cma to the compiler,
containing Parsedtree rewriter functions, which are called through the @
notation. One just has to be careful giving cma to ocamlc/ocamlopt and cmxa
to ocamlc.opt/ocamlopt.opt.

ph.

2013/2/2 Leo White <lpw25 at cam.ac.uk>

>    (@deriving ["sexp"; "json"])
>>   type t = F of int | G of s
>>    and s = H of (t * t)
>>
>> or
>>
>>    (@perform)
>>       (x <-- m;
>>        y <-- n;
>>        return (x y))
>>
>> In order for this to be valid code, 'deriving' and 'perform' should
>> resolve to functions of appropriate types:
>>
>>    val deriving : string list -> Parsetree.structure_item ->
>> Parsetree.structure_item
>>
>>    val perform : Parsetree.expression -> Parsetree.expression
>>
>>
> I have a broader proposal that is along these lines, which is intended to
> be the second part of my earlier blog post. There are in general some
> difficulties with just calling functions during parsing, but I think the
> general idea of declared extensions is the right way to do things.
>
> The reason I haven't mentioned this proposal yet, is that it is a more
> long term proposal. We can easily implement the changes needed to support
> ppx before the next OCaml release. Whereas full support for declared
> extensions will require more time, and probably a lot more debate before it
> can be included.
>
> Since moving an extension from ppx to some kind of declared mechanism
> would require only minimal work, I see no harm in promoting ppx in the
> short/medium term, while also developing a more complete solution.
>
> In particular I think that the extension/template syntaxes ( "(: lid
> expr)", "{: lid { string }}", etc.) that have been discussed so far will be
> a very good match for a declaration based mechanism. It is also another
> argument for forcing extensions to have names.
>
> I will try to put my own proposals in that blog post early next week.
>
> ______________________________**_________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/**listinfo/wg-camlp4<http://lists.ocaml.org/listinfo/wg-camlp4>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130203/a8887181/attachment.html>