I'll confess to not having looked closely at the example, which is sort of a degenerate case. But enforcing precedence is *not* the same as removing ambiguity.
Note that the precedence, especially in this case, is *general precedence*, as opposed to the operator precedence you'll find in the textbooks. Marpa implements operator precedence as a subcase of general precedence. General precedence is AFAICT my discovery -- no parser before Marpa could have implemented it efficiently, and I don't know of it being described anywhere in the literature. If you think the above does not "want" ambiguity, you should work out an alternative interpretation of the meaning of operatorless precedenced statements. I can (I think) claim the first word in general precedence parsing, but that does not mean it will be the last word. :-) On Fri, Sep 2, 2016 at 1:49 PM, Anton Dyudin <[email protected]> wrote: > It seems clear to me that > > option ::= opt1a || opt2a > opt1a ::= 'a' > opt2a ::= 'a' 'a' > > doesn't want ambiguity; but that the BNF rewrite does introduce it, by > treating the || as an ambiguous option. Or is it supposed to be precedenced > only in recursive contexts? > > On Friday, 2 September 2016, Jeffrey Kegler <[email protected] > om> wrote: > >> If you *want* ambiguity, consider avoiding the precedenced rule syntax >> and writing it directly in BNF. Precedenced rules are intended to cover >> the ordinary cases. If you're doing advanced and tricky stuff, laying it >> out in pure BNF forces you to make it clear exactly what you meant. >> >> I find that many systems, with their advanced features and syntaxes, go >> too far in the DWIMery. This is handy if their "Do What I Mean" is in fact >> what you meant. But if the DWIMery guesses wrong, the system just makes >> things more complicated. So I try to not make my advanced features *too* >> smart. >> >> On Thu, Sep 1, 2016 at 11:48 AM, <[email protected]> wrote: >> >>> Thanks for the pointer to prose on the rule rewriting. I can read Perl >>> about as well as middle English -- lots of effort and guessing, and usually >>> getting pretty close. :-) >>> >>> Further comments inline below. >>> >>> On Wednesday, August 31, 2016 at 10:10:01 PM UTC-6, Jeffrey Kegler wrote: >>> >>>> Just in case it was unclear, that last message was aimed at the general >>>> reader of this read, and was not ad hominem. >>>> >>> >>> No offense taken -- it sounds like great advice to me in particular! >>> >>> @Anton: Off the top of my head, 2+3+4 is ambiguous in that grammar -- >>>> the BNF does not implement associativity. >>>> >>> >>> So SLIF has an implied, default associativity? I can find one IRC >>> comment to this effect, but I can't find it anywhere in the docs. (There's >>> a great potential spot in Scanless/DSL.pod where it discusses >>> associativity....) >>> >>> This explains why my parse was not ambiguous. What if I *want* my >>> grammar to be ambiguous in this case? I saw another IRC comment asking for >>> an adverb setting for associativity of "none". Is this possible? >>> >>> Thanks! >>> >>> - Ryan >>> >>> <snip> >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > -- > 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. > -- 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.
