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!