3 parsers actually.<div>The original parser, the parser to patt, the parser to expr.</div><div>Besides, every user has to maintain 3 parsers if they want to use the quotation, not only the compiler maintainer. </div><div>I would be happy to see a prototype work before other changes<br>
<br><div class="gmail_quote">On Mon, Jan 28, 2013 at 1:25 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">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I suggest that you might think twice before you think it's a viable option<br>
---------------------------<br></div>
2. *Copy and paste, creating two new versions of the parser. *One<div class="im"><br>
version will directly return Haskell abstract syntax for a Haskell<br>
pattern, and the other will return Haskell abstract syntax for an<br>
expression.<br></div>
*This is potentially a maintenance nightmare.*<br>
</blockquote>
<br>
This part is referring to needing two parsing functions: one for the when the quotation is used as a pattern and one for when it is used as an expression. I don't think that needing two parsing functions is really a "maintenance nightmare". Also, with GADTs they don't need to be two separate functions anyway.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Furthermore, we lose a lot of the benefits of the type checker:<br>
a value of type TH.ExpQ is Haskell abstract syntax for an<br>
expression, but knowing this tells us nothing about the type of<br>
the Haskell expression represented by the abstract syntax. This<br>
expression could be an Integer, a String or have any other<br>
type—we know only that it is syntactically correct, not that it is<br>
type correct.<br>
</blockquote>
<br></div>
This is a fair criticism: parsing to a value and then converting that into an AST fragment may catch some potential errors in a parser. However, this safety could also be obtained by creating the value and the AST in parallel, and simply discarding the data structure when parsing is finished. This may not be as "neat" as deriving the AST from the value, but it is also requires no special support.<br>

<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo
</div>