Hi all,<br><br>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. <br>

<br>So as a potential user, I'd buy it without hesitation, but maybe there is some limitation I overlooked?<br><br>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.<br>

<br>ph.<br><br><div class="gmail_quote">2013/2/2 Leo White <span dir="ltr"><<a href="mailto:lpw25@cam.ac.uk" target="_blank">lpw25@cam.ac.uk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  (@deriving ["sexp"; "json"])<br>
  type t = F of int | G of s<br>
   and s = H of (t * t)<br>
<br>
or<br>
<br>
   (@perform)<br>
      (x <-- m;<br>
       y <-- n;<br>
       return (x y))<br>
<br>
In order for this to be valid code, 'deriving' and 'perform' should<br>
resolve to functions of appropriate types:<br>
<br>
   val deriving : string list -> Parsetree.structure_item -><br>
Parsetree.structure_item<br>
<br>
   val perform : Parsetree.expression -> Parsetree.expression<br>
<br>
</blockquote>
<br></div>
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.<br>


<br>
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.<br>


<br>
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.<br>
<br>
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.<br>


<br>
I will try to put my own proposals in that blog post early next week.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
wg-camlp4 mailing list<br>
<a href="mailto:wg-camlp4@lists.ocaml.org" target="_blank">wg-camlp4@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/<u></u>listinfo/wg-camlp4</a><br>
</div></div></blockquote></div><br>