Re: [9fans] bison problem, not plan9 related

[Russ Cox <rsc@swtch.com>]

> Ok, thanks, this seems to have solved it.
> So the %nonassoc says to the parser that
> (REP block) ATOM
> is the right decision as opposed to
> REP (block ATOM)
> right?

%token declares its arguments as tokens but
does not give them any precedence level.

%left, %right, and %nonassoc also declare their
arguments as tokens.  in addition, each such line
introduces a new precedence level stronger than
the ones introduced by previous lines.

if a shift/reduce conflict involves different precedences,
the stronger precedence always wins.

if a shift/reduce conflict is a tie between identical precedences,
the resolution depends on which of the three lines
(%left, %right, or %nonassoc) introduced the precedence.

precedences introduced by %left resolve the tie
by reducing; this creates left-to-right associativity (x-y-z).

precedences introduced by %right resolve the tie
by shifting; this creates right-to-left associativity (x^y^z in hoc).

precedences introduced by %nonassoc do not resolve
the tie.  they leave it as a conflict that gets reported.

if you're defining a precedence that is not intended
to be associative, much of the time it doesn't matter
which you pick, because your grammar is likely to
be such that ties never happen.  but %nonassoc is
still the safe choice.

in the running example, %nonassoc by itself
doesn't say which of those two is right.  it just
defines a precedence for ATOM, which is used
as the precedence for shifting ATOM.
because the REP block and block block rules
have precedences too, the ambiguity can be
resolved by comparing the precedences.
which way things get resolved depends on whether
the %nonassoc line comes before or after the
other precedences, not on the meaning of %nonassoc.

i said

> %left '+'
> %left REP
> %nonassoc ATOM

and that will give you REP block ATOM == REP (block ATOM)
which is probably not what you want.  to tweak it,
just move the %nonassoc line above the two %left lines.

russ