Operator associativity
Operator associativity determines what happens when an operand is surrounded by operators of the same precedence, as in 1-2-3: An operator can be left-associative, right-associative, or non-associative. Left-associative operators are applied to operands in left-to-right order while right-associative operators are the other way round. The basic arithmetic operators are normally all left-associative, which means that 1-2-3 = (1-2)-3 ≠ 1-(2-3), for instance. This does not hold true for higher operators. For example, exponentiation is normally right-associative in mathematics, but is implemented as left-associative in some computer applications like Excel. In programming languages where assignment is implemented as an operator, that operator is often right-associative. If so, a statement like would be equivalent to , which means that the value of c is copied to b which is then copied to a. An operator which is non-associative cannot compete for operands with operators of equal precedence. In Prolog for example, the infix operator is non-associative, so constructs such as are syntax errors. Unary prefix operators such as − (negation) or sin (trigonometric function) are typically associative prefix operators. When more than one associative prefix or postfix operator of equal precedence precedes or succeeds an operand, the operators closest to the operand goes first. So −sin x = −(sin x), and sin -x = sin(-x). Mathematically oriented languages (such as on scientific calculators) sometimes allow implicit multiplication with higher priority than prefix operators (such as sin), so that sin 2x+1 = (sin(2x))+1, for instance. However, prefix (and postfix) operators do not ''necessarily'' have higher precedence than all infix operators. Some (hypothetical) programming language may well have an operator called sin with a precedence lower than × but higher than + for instance. In such a language, sin 2·x+1 = sin(2·x)+1 would be true, instead of (sin 2)·x+1, as would normally be the case. The rules for expression evaluation are usually three-fold: # Treat any sub-expression in parentheses as a single recursively-evaluated operand (there may be different kinds of parentheses though, with different semantics). # Bind operands to operators of higher precedence before those of lower precedence. # For equal precedence, bind operands to operators according to the associativity of the operators. Some more examples: : :Generalizations of Common Operator Notation
The use of operator precedence classes and associativities is just one way. However, it is not the most general way: this model cannot give an operator more precedence when competing with '−' than it can when competing with '+', while still giving '+' and '−' equivalent precedences and associativities. A generalized version of this model (in which each operator can be given independent left and right precedences) can be found aSee also
*References
{{DEFAULTSORT:Common Operator Notation Computer arithmetic Operators (programming)