Robert Grimm wrote:
Sure. I went back to our emails and to the CVS logs.
Thanks! As PEGs are still quite new, it's good to build a collection of
common issues, so that people can learn to identify and solve them.
[... various issues]
In summary: Yes, there can be subtle ordering problems, but they usually
show quickly during testing. And for the really hard ones, you have to
hope for Terence's sharp eyes and mind. :) Also, a more subtle class of
problems can be caused by interactions between (legal) empty inputs and
greediness. At the same time, once discovered, the solutions are simple:
reorder for the former case and add a predicate in the latter case.
To put this in perspective: I have translated my Java grammar to Scott
McPeak's Elkhound. I got 18 shift-reduce and 3 reduce-reduce conflicts.
I then had to test across a range of source files to find out that only
2 of these conflicts were real conflicts requiring explicit
disambiguation. Additionally, I had an extremely frustrating day trying
to translate the token-level productions into flex rules, with the end
result being considerably less precise than Rats!.
Don't get me wrong: I like Elkhound. It is a good tool with very nice
insights into GLR parsing behind it. But it too presents some subtle
debugging issues...
Don't worry, I've been convinced for some time now that ambiguity in
context-free grammars is a serious issue, and one too easily overseen by
the GLR community. As you put in your previous email, PEGs offer a
different compromise, and are not exempt of decision issues of their
own. As mentioned in a different thread, my own credo is that all these
grammars should be verified and proven free of any issue instead of
relying on testing only.
--
Sylvain
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
