On Sun, Nov 3, 2013 at 12:46 PM, Robert Schadek <realburner@gmx.de> wrote:
On 11/03/2013 09:13 AM, Philippe Sigaud wrote:

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 :)

 
Other promising options are using lemon, a LALR(1) parser generator.

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.

I guess I'll have to write a CT-compatible LALR(1) engine...
 
D does not fit into LALR(1), you need glr.

how about dparser (nothing to do with D btw): http://dparser.sourceforge.net/
the grammar for C looks quite compact and clean: http://dparser.sourceforge.net/d/tests/ansic.test.g


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.

Sure, but that'd be a 2nd priority after having at least one (partially) automatically generated parser for D.