2009/10/21 Russ Cox <r...@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
