D parsing

[Philippe Sigaud]

Manfred:
>One prerequisite for every PEG-Parser is, that
>the language has to be designed to be without any ambiguity.
>
>This is not the case for D, because of its evolution
> based on recursive descent parsing including tricks.
>
>It is therefore not sufficient to eliminate bugs in Pegged.

That's right. I should test it with 2.064, though, as soon as it's out.
I also have a fully recursive parser that manages ambiguity quite well
(gives all possible parse trees), but that's not what I want for a
programming language.

What we need is a parser able to deal with left-recursive BNF grammar. That
way, we can feed it the D grammar.

Note that Pegged has no problem with the official C grammar or the officiel
XML specification...

Andrei:
> That would mean Pegged should accommodate tricks. Very few languages
don't have them.

That was ma conclusion also, even if that means stepping outside of what a
PEG is. I just fear losing some of their proprieties.
I really like the composability of PEGs: you can inject / call another
grammar inside another one: creating a grammar becomes a bit like
structured programming, with functions and recursions. That means you can
'grow' your grammar by steps. That's really really nice to have.

Also, discarding the 'scannerless' part of PEGs (to connect the parser to
the token range resulting from DScanner, for example), or dealing with
left-recursion means changing the internal engine.

Of course, that can be done : the engine could be changed according to
compile-time parameters. I 'just' need to code the parsers themsevels :)

Bah, you're getting me all interested in it again! I wanted to write a D
tutorial around a ray-tracer!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131102/0c792f67/attachment.html>