|Implicit operator precedence email@example.com (2004-05-30)|
|Re: Implicit operator precedence firstname.lastname@example.org (SM Ryan) (2004-06-06)|
|Re: Implicit operator precedence email@example.com (Hans Aberg) (2004-06-15)|
|From:||Hans Aberg <firstname.lastname@example.org>|
|Date:||15 Jun 2004 01:01:22 -0400|
|Posted-Date:||15 Jun 2004 01:01:22 EDT|
email@example.com (Sam Thursfield) wrote:
>Recently i've been toying with writing a yacc-style (LALR) parser
>generator. It's got to the point where it can create a fully working
>version of the infix calculator given in the bison manual.
>When it came to implementing operator precedence, as a quick hack i
>worked out that instead of all the %left DIV MUL business, i could
>simply put the rules in order and resolve shift/reduce conflicts by
>the number of the rule.
Even though POSIX requires Yacc-like parser generators to resolve conflicts
by reducing the first rule in the grammar, it is in general something that
depends on the compiler, and not the grammar.
>question is, can anyone see any obvious problems with this setup?
>[How do you tell it that ADD and SUB have the same precedence? -John]
And shift/reduce conflicts will always be resolved as reduce, so one can't
express %right and %nonassoc that way.
Return to the
Search the comp.compilers archives again.