Lepl doesn't warn about ambiguities because it was designed to handle
ambiguous grammars (ie return more than one possible parse). However, in
retrospect I guess it would be a good idea to add this as an option (I have
to admit that I am not sure how, or even if it is possible, in a recursive
descent parser, to do this).
A FullFirstMatchException means that the entire input was not consumed.
The usual fix for that is to require that the match consume everything by
adding Eos() at the end of the grammar. That's probably all you need here.
For debugging in general, the first thing I do is add variable tracing -
http://www.acooke.org/lepl/debugging.html#index-15 For that to work well,
it's best to break your grammar into many small pieces (what you have is
fine). If you do that you will probably be surprised by something
(something will match when it shouldn't, or not match when it should),
which will lead to your bug.
Another thing that is sometimes useful is to disable the full first match
and print out all possible parses. Looking at the different possible
results and reasoning about how they happened can lead to understanding the
issue (particularly if you can isolate the problem to a small subset of the
Just looking at your grammar, one possible problem is that AnyBut(...)
will match spaces, which I think you are not expecting?
Does that help? I agree with your basic point, that some kind of warning
would help here, but hopefully the above will do instead...?
On Mon, 25 Oct 2010 09:41:47 -0400, Neal Becker <ndbeck...@gmail.com>