On Wednesday, 1 October 2014 15:17:34 UTC+10, Jeffrey Kegler wrote: > > OK. Ambiguity is a property of the parse (grammar + input). Typically > you'll only check for it once the input is complete. So checking inside > the read()/resume() loop is not something you'll typically do, because the > interim values will be for the input so far -- not the input at the point > where you plan to actually do the parse. And the ambiguity with the input > you plan to parse will usually be what you are interested in. (All this is > assuming you're not up to some very advanced technique.) > > Typically you'll > > 1.) Create the recognizer with new(). > > 2.) Start reading the input with read(). > > 3.) If you're doing event processing, loop, reading more input with > resume(), until you're done. > > 4.) HERE is the point where you'll usually check for ambiguity. Your > input is complete, and you've yet to call value(). The reason you'll > probably do it here is that depending on the result, > you may want to handle calling value() differently, or not do it at all. >
That makes sense. > 5.) Call value. > > You *can* call ambiguous() at any point after step 2. But it usually > won't make sense until step 4. After that, you can call it anywhere, and > get the same value. (Because ambiguity is about grammar+input and after > step 3 the input is complete.) > > Your code looks like it is calling ambiguous() at all sorts of odd > locations and, accordingly, getting all sorts of odd answers. > I was experimenting to see what to call when. > Does this help? I answered after skimming the code, and if I've missed > the intent let me know and I'll look more closely. > A quick note in the docs re your 5 points would be good. -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
