<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/03/2013 09:13 AM, Philippe Sigaud
wrote:<br>
</div>
<blockquote
cite="mid:CAOA6Bi6RD-LDbWq=huP=w9qWxU516nHTVQOuvmdVdTp=Ybx9tQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<div>Oh, for D it works (it's even the biggest grammar I
know), but it's too slow to be of practical interest. But
that just means the generated parser is not top-notch,
which is reasonable: I'm not a parsing pro, just a guy
doing this during his free time :)</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">Other promising options are
using lemon, a LALR(1) parser generator.</div>
</div>
</blockquote>
<div><br>
</div>
<div>My current plan is to write different engines, and
letting either the user select them at compile-time, or to
have the parser decide which one to use, depending on the
grammar. I'm pretty sure the 'Type 3' parts of a grammar
(regular expressions) could be bone by using std.regex,
for example.</div>
<div><br>
</div>
<div>I guess I'll have to write a CT-compatible LALR(1)
engine...</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
D does not fit into LALR(1), you need glr. <br>
<br>
Another idea would be to make the engine a template argument, and
than combine multiple parser!(engines). And even allow hand written
stuff. This way you could use ll(1) for the ll(1) parts and the
crazy hand written black magic for the hard parts.<br>
</body>
</html>