<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:16px">Manfred:</span><div><span style="font-family:arial,sans-serif;font-size:16px">>One prerequisite for every PEG-Parser is, that</span></div><div><span style="font-family:arial,sans-serif;font-size:16px">>the language has to be </span><span style="font-family:arial,sans-serif;font-size:16px">designed to be without any ambiguity.</span><br style="font-family:arial,sans-serif;font-size:16px">
><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">>This is not the case for D, because of its evolution </span></div><div><span style="font-family:arial,sans-serif;font-size:16px">> based on recursive </span><span style="font-family:arial,sans-serif;font-size:16px">descent parsing including tricks.</span><br style="font-family:arial,sans-serif;font-size:16px">
><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">>It is therefore not sufficient to eliminate bugs in Pegged.</span><div><br></div><div>That's right. I should test it with 2.064, though, as soon as it's out.</div>
<div>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.</div><div><br></div><div>What we need is a parser able to deal with left-recursive BNF grammar. That way, we can feed it the D grammar.</div>
<div><br></div><div>Note that Pegged has no problem with the official C grammar or the officiel XML specification... </div><div><br></div><div>Andrei:</div><div><span style="font-family:arial,sans-serif;font-size:16px">> That would mean Pegged should accommodate tricks. Very few languages don't have them.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:16px"><br></span></div><div>That was ma conclusion also, even if that means stepping outside of what a PEG is. I just fear losing some of their proprieties.<div>
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.<br>
</div></div></div><div><br></div><div>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.</div>
<div><br></div><div>Of course, that can be done : the engine could be changed according to compile-time parameters. I 'just' need to code the parsers themsevels :)</div><div><br></div><div>Bah, you're getting me all interested in it again! I wanted to write a D tutorial around a ray-tracer!</div>
</div>