<div><br></div>After you doing all those stuff,  I am worried that you may find you just re-implemented a new P4.<div><br></div><div><b>I agree that the complexity of extensible parser should be removed,  there's a compromise here.</b></div>
<div><br></div><div>The ppx<b> shares the same Intermediate Ast</b>(It could be improved with more meaningful tags names)  with camlp4 but uses the built in parser.</div><div><br></div><div>The benefit lies in two aspects:</div>
<div>    1. You get the automatically meta filter, quasi-quotation is for free</div><div>    2. The camlp4 can works well with ppx, the change is incremental, most existing library still works under both cases </div><div>
<br></div><div>Introducing an Intermediate Ast also gives you some freedom, the parsetree does a lot of syntax desguaring(to name a few, range patterns, bigarray, string access, array access), you may change<br>the representation of parsetree, but that introduces complexity in other cases, so my suggestion is that we can separate extensible parser part from camlp4, that's absolutely doable, then we share the same intermediate Ast</div>
<div><br><div class="gmail_quote">On Mon, Jan 28, 2013 at 4:01 PM, Leo White <span dir="ltr"><<a href="mailto:lpw25@cam.ac.uk" target="_blank">lpw25@cam.ac.uk</a>></span> wrote:<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">
3 parsers actually.<br>
The original parser, the parser to patt, the parser to expr.<br>
</blockquote>
<br></div>
The original parser isn't necessary for the quotation, and of course the other two parsers are only both needed if you want the quotation to work as both a pattern and an expression.<br>
<br>
Anyway, my point is that you do not *need* to implement quotations by parsing to a value and then converting to an AST fragment, in fact it is often easier not to.<br>
<br>
That is not to say that some people might not want to implement their quotations by parsing to a value and then converting to an AST fragment. In fact, if they want to use an external parser (over which they have little control) to parse their quotations then they may have to do it that way.<br>

<br>
For these cases I think there are three options:<br>
<br>
1. They can implement conversion functions by hand.<br>
<br>
2. They could use some kind of type-conv style extension to automatically produce the conversion functions. I'm sure such an extension would be welcomed by other extension authors.<br>
<br>
3. If/when some kind of run-time type representation is added to the language, it could be used to create a generic conversion function.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo
</div>