Next: Precedence Examples, Previous: Specifying Operator Precedence, Up: Operator Precedence [Contents][Index]
Since POSIX Yacc defines only %left
, %right
, and
%nonassoc
, which all defines precedence and associativity, little
attention is paid to the fact that precedence cannot be defined without
defining associativity. Yet, sometimes, when trying to solve a
conflict, precedence suffices. In such a case, using %left
,
%right
, or %nonassoc
might hide future (associativity
related) conflicts that would remain hidden.
The dangling else
ambiguity (see Shift/Reduce Conflicts) can be solved
explicitly. This shift/reduce conflicts occurs in the following situation,
where the period denotes the current parsing state:
if e1 then if e2 then s1 • else s2
The conflict involves the reduction of the rule ‘IF expr THEN
stmt’, which precedence is by default that of its last token
(THEN
), and the shifting of the token ELSE
. The usual
disambiguation (attach the else
to the closest if
),
shifting must be preferred, i.e., the precedence of ELSE
must be
higher than that of THEN
. But neither is expected to be involved
in an associativity related conflict, which can be specified as follows.
%precedence THEN %precedence ELSE
The unary-minus is another typical example where associativity is usually
over-specified, see Infix Notation Calculator: calc
. The %left
directive is
traditionally used to declare the precedence of NEG
, which is more
than needed since it also defines its associativity. While this is harmless
in the traditional example, who knows how NEG
might be used in future
evolutions of the grammar…