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

[Rudolf Sykora <rudolf.sykora@gmail.com>]

2009/10/21 Russ Cox <rsc@swtch.com>:
> To know how to decide, yacc needs a precedence
> for the thing being shifted and the rule.  You've
> given precedences for each rule (REP block has
> REP's precedence, and block block has +'s thanks
> to the override) but not to ATOM.
>
> Concretely, when yacc sees REP block ATOM
> it isn't sure whether that's (REP block) ATOM or
> REP (block ATOM).
>
> Instead of
>
>> %token  ATOM
>> %left   '+'
>> %left   REP
>
> you probably want
>
> %left '+'
> %left REP
> %nonassoc ATOM
>
> Russ

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?

The sad point really is that I couldn't find a good explanation for
what %nonassoc really means. Everybody just says that it precludes a
situation where
'the same operator would be twice in a row...'
which isn't quite telling, when one realizes that the parser really
does not know what an 'operator' is... (both the documentation of
bison (Donnelly, Stallman) and of yacc (Johnson) are just like that; I
couldn't find any better)
So could you please say, what %nonassoc really assures?

Thanks
Ruda