I wouldn't rush to declare victory for 1 + 2a + b being (* (+ 1 2) (+ a b)), but I get your point. Precedence in "option = a || a a" can't escape to affect option* around it.
On Friday, 2 September 2016, Jeffrey Kegler <[email protected]> wrote: > @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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','marpa-parser%[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] > <javascript:_e(%7B%7D,'cvml','marpa-parser%[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.
