About ambiguity and precedence. You easily run into it if you try to have implied operators.
Imagine someone trying to leave multiplication as implied. Eliminate the unary plus and it becomes (I think) unambiguous: E ::= Number || E '+' E || E E It's unambiguous, that is, '1 + 2 3 + 4' parses as (1+2)(3+4). This is very, very cool and far beyond what other parsers can do. The reason I haven't bragged on this is that is you do something reasonable like add unary plus: E ::= Number || '+' E || E '+' E || E E you get these parses: ((1,+,2),(3,+,4)) ((1,(+,2)),(3,+,4)) (((1,+,2),3),(+,4)) (((1,(+,2)),3),(+,4)) All of these obey precedence. On Fri, Sep 2, 2016 at 4:24 PM, <[email protected]> wrote: > A degenerate case isn't necessarily invalid. :-) I tried for a very > simple non-recursive precedence rule. > > So what does "precedence" mean in a Marpa grammar then? AFAICT, it means > whatever grammar you get from the rewriting rules. It's clear that the > results for recursive arithmetic examples match my understanding of the > term. In this case, using the precedenced choice operator removes > ambiguity. I didn't expect recursion to be an essential ingredient. > > If convenient, I would enjoy seeing a "precedenced statement that remains > ambiguous." Like @Anton Dyudin, I expected to be able to prune ambiguity > via precedence. > > FYI, this isn't idle speculation. My target language to parse, VHDL, > dictates different semantics in some contexts for identifiers versus > general expressions [1]. But of course, a lone identifier is also a valid > expression. To achieve the Marpa ideal of "semantic parsing straight from > BNF", I hoped to use precedence to give the identifier priority and > suppress the ambiguity. > > Please forgive any whininess that may have slipped through in this post. > You have done an amazing job with Marpa! My aims are to (1) understand > Marpa's capabilities, intents, definitions, etc., and (2) figure out how to > best use Marpa for my application (parsing VHDL). > > Thanks! > > - Ryan > > [1] For an actual in an association list, a bare signal name (identifier) > is hooked directly to the formal. An expression in this same context > infers an anonymous signal, which incurs a delta delay relative to the > straight identifier. The full rules (VHDL-2008) are more complex. > > On Friday, September 2, 2016 at 3:04:19 PM UTC-6, Jeffrey Kegler wrote: >> >> 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. :-) >> >> >> -- > 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.
