<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 21, 2011, at 1:14 PM, reed kotler wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#ffffff" text="#000000">
On 10/21/2011 09:28 AM, Owen Anderson wrote:
<blockquote cite="mid:CBCB3A69-FA3F-48C7-8B66-2D4B1C7275AD@mac.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Reed,
<div><br>
<div>
<div>On Oct 20, 2011, at 9:47 AM, Reed Kotler wrote:</div>
<blockquote type="cite">
<div>I would like to see the many adhoc parsers in LLVM get
replaced by ones <br>
generated from grammars.<br>
</div>
</blockquote>
</div>
</div>
<div><br>
</div>
<div>FYI, this is very unlikely to happen. The parsers in LLVM <i>were</i>
historically generated from grammars (bison, as I recall), and
those implementations were removed in favor of hand-written
implementations both because the latter were significantly
easier to maintain, and because they were much better suited to
offer reasonable diagnostics. Any plan to reverse that
decisions is likely to meet a lot of resistance.</div>
<div><br>
</div>
<div>--Owen</div></blockquote></div></blockquote><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
Right now it's pretty easy to crash tablegen if you have table
errors, for example. That is not exactly giving reasonable
diagnostics.<br></div></blockquote></div><br><div>Reed, as I'm sure you know and can appreciate… the cause of most of these problems is not the parser itself, it's the semantic analysis and other actions that are fired by the parser. I don't see how a machine generated parser helps solve the important problems here.</div><div><br></div><div>-Chris</div></body></html>