<div dir="ltr">On Sun, Nov 3, 2013 at 7:08 PM, Timothee Cour <span dir="ltr"><<a href="mailto:thelastmammoth@gmail.com" target="_blank">thelastmammoth@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><span style="color:rgb(80,0,80)">On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:philippe.sigaud@gmail.com" target="_blank">philippe.sigaud@gmail.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>
<div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">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.<br>
</div></div></div></blockquote></div><div class="im"><div><br></div></div><div>even lexing can't be done with regex, eg nesting comments : /+ ... +/</div><div>Also, although it may seem cleaner at first to combine lexing and parsing in 1 big grammar (as done in pegged), it usually is faster do feed a (separate) lexer output into parser. </div>
</div></div></div></blockquote><div><br></div><div>Lexing, yes. I was imprecise: even in a context-free grammar, some rules are regular and could use std.regex (the ct part) as the underlying engine, just for that rule.</div>
<div><br></div><div><br></div><div><br></div></div></div></div>