D parsing

[Timothee Cour]

On Sun, Nov 3, 2013 at 12:46 PM, Robert Schadek <realburner at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131103/6a55e5ba/attachment.html>