On Oct 20, 2006, at 11:18 AM, Bryan Alexander Ford wrote:
Quoting David Mercer <[EMAIL PROTECTED]>:
Robert Grimm wrote:
I agree with Terence in that ambiguity vs. ordering is a trade-off.
With CFGs you may get unnecessary ambiguity and with PEGs you may
get
subtle ordering errors.
Ah, so now you're persuading me the other way. At least with
ambiguity, you
can discover the problem when the grammar is compiled, but subtle
ordering
errors you may or may not discover...
Actually, I'm pretty much convinced (though I haven't demonstrated
it yet) that
pretty much the same grammar analysis techniques that LR/LALR-style
parser
generators use to detect ambiguities and produce their parse tables
could
easily be adapted to find unanticipated ordering dependencies in
PEGs, with
precisely the same capabilities and limitations.
That's sort of what I'm saying. I use LL(*) analysis by default and
failover to packrat only when LL(*) analysis fails to find a DFA that
represents the regular (non recursive) lookahead. I get lots of nice
errors for ambiguities and such. I hush them with backtrack=true
option when I'm convinced they are what I want.
I think at one point (maybe in my MS thesis?) I proposed as future
work adding
an "unordered choice" operator '|' to a PEG-based parser generator,
which would
more or less reduce to the standard ordered choice operator '/',
but only if the
parser generator can successfully verify (e.g., using LR-style
analysis
techniques) that the different alternatives are indeed order-
independent (or
perhaps have a single obviously correct order like 'X Y | X |
<empty>').
I also toyed with using combined | and / in the same list of
productions.
Ter
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
