@Anton: precedence is about what parses are allowed in nested expressions. Precedence with zero-depth nesting is like a triangle with a zero-degree angle. Mathematicians call things like this degenerate -- yes, a 0-degree triangle *is* a valid triangle, but it's also an annoying, tricky and ultimately uninteresting special case.
On Fri, Sep 2, 2016 at 5:21 PM, Jeffrey Kegler < [email protected]> wrote: > 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.
