ambiguities

[Neal Becker]

I don't understand why my grammar is seeming to suffer from ambiguity, as
evidenced by the FullFirstMatchException.

This is supposed to parse command line options, in several styles.

#'--no-limit'
el1 = Drop ("'--") & AnyBut("'=")[1:,...] & Drop ("'") > value_to_dict
#'--thresh=0.4' or '-u=0.4'
el2 = Drop ("'") & ~Literal('-')[1:] & AnyBut("'=")[1:,...] & Drop ("=") &
AnyBut("'")[1:,...] & Drop ("'") > tuple_to_dict
#'--thresh' '0.4' or '-u' '0.4'
el3 = Drop ("'") & ~Literal('-')[1:] & AnyBut("'=")[1:,...] & Drop ("' '") &
~Lookahead('-') & AnyBut("'=")[1:,...] & Drop ("'") > tuple_to_dict

spaces = ~Space()[:]
with Separator(spaces):
line1 = ~String("'") & (el3 | el2 | el1)[1:] > combine

test = "'/home/nbecker/scma-ldpc-fixed/test/test_ldpc_pipelined.py' '--no-
limit' '--uw-detectors' '72' '--uw-detect-parallel' '4' '--thresh' '0.4' '--
max-iter' '29' '--shadowing' '6' '--user-distr' 'poisson' '--detect-per-uw'
'1' '--max-error' '100' '--fade-type' 'phase_noise' '--decoder-iter' '7' '--
aperture' '128' '--rand-freq' '4.4e-4' '--pipeline' '7' '--alpha=0.55' '--max-
detect' '13' '-u' '4' '--esno=2' '--
log=test_ldpc_pipelined.py.nbecker6.da6707d2b497ae30c5b271e23201ea0a.err'"

test2 = "'/home/nbecker/scma-ldpc-fixed/test/test_ldpc_pipelined.py' '--no-
limit' '--max-iter=15' '--aperture=100' '--uw-xmit-keepout=2.5' '--uw-
detectors=63' '--uw-detect-parallel=4' '--thresh=0.4' '--max-detect=13' '--
user-dist=deterministic' '--print=60' '--max-time=14400' '--shadowing=4' '-
u=8' '--esno=-1' '--
log=test_ldpc_hw2.py.nbecker6.06d8beb63730f51b1e45f518568d674b.err'"

When line1 is given as (el1 | el2 | el3) it gives an error, but not when given
as (el3 | el2 | el1), using the two tests

line1.parse (test)
line1.parse(test2)

But more important, I'm troubled that I don't know how to debug it. I'm used
to bison telling me about conflicts, and they are generally not that hard to
understand. But I don't know how to go about debugging this one.

[andrew cooke]

Hi,

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
grammar).

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...?

Cheers,
Andrew

On Mon, 25 Oct 2010 09:41:47 -0400, Neal Becker <ndbe...@gmail.com>
wrote: