Operator associativity
In programming language theory, the associativity of an operator is a property that determines how operators of the same precedence are grouped in the absence of parentheses. If an operand is both preceded and followed by operators (for example, codice_1), and those operators have equal precedence, then the operand may be used as input to two different operations (i.e. the two operations indicated by the two operators). The choice of which operations to apply the operand to, is determined by the associativity of the operators. Operators may be associative (meaning the operations can be grouped arbitrarily), left-associative  (meaning the operations are grouped from the left), right-associative (meaning the operations are grouped from the right) or non-associative (meaning operations cannot be chained, often because the output type is incompatible with the input types). The associativity and precedence of an operator is a part of the definition of the programming language; different programming languages may have different associativity and precedence for the same type of operator. Consider the expression codice_2. If the operator codice_3 has left associativity, this expression would be interpreted as codice_4. If the operator has right associativity, the expression would be interpreted as  codice_5. If the operator is non-associative, the expression might be a syntax error, or it might have some special meaning. Some mathematical operators have inherent associativity. For example, subtraction and division, as used in conventional math notation, are inherently left-associative. Addition and multiplication, by contrast, are both left and right associative. (e.g. codice_6). Many programming language manuals provide a table of operator precedence and associativity; see, for example, the table for C and C++. The concept of notational associativity described here is related to, but different from, the mathematical associativity. An operation that is mathematically associative, by definition  requires no notational associativity. (For example, addition has the associative property, therefore it does not have to be either left associative or right associative.) An operation that is not mathematically associative, however, must be notationally left-, right-, or non-associative. (For example, subtraction does not have the associative property, therefore it must have notational associativity.) Examples. Associativity is only needed when the operators in an expression have the same precedence. Usually codice_7 and codice_8 have the same precedence. Consider the expression codice_9. The result could be either codice_10 or codice_11. The former result corresponds to the case when codice_7 and  codice_8 are left-associative, the latter to when codice_7 and codice_8 are right-associative. In order to reflect normal usage, addition, subtraction, multiplication, and division operators are usually left-associative, while for an exponentiation operator (if present) and Knuth's up-arrow operators there is no general agreement. Any assignment operators are typically right-associative. To prevent cases where operands would be associated with two operators, or no operator at all, operators with the same precedence must have the same associativity. A detailed example. Consider the expression codice_16, in which codice_17 is taken to be a right-associative exponentiation operator . A parser reading the tokens from left to right would apply the associativity rule to a branch, because of the right-associativity of codice_17, in the following way: This can then be evaluated depth-first, starting at the top node (the first codice_17): A left-associative evaluation would have resulted in the parse tree codice_37 and the completely different results 625, 244140625 and finally ~5.9604645 × 10. Right-associativity of assignment operators. In many imperative programming languages, the assignment operator is defined to be right-associative, and assignment is defined to be an expression (which evaluates to a value), not  just a statement. This allows chained assignment by using the value of one assignment expression as the right operand of the next assignment expression. In C, the assignment codice_38 is an expression that evaluates to the same value as the expression codice_39 converted to the type of codice_40, with the side effect of storing the R-value of codice_39 into the L-value of codice_40. Therefore the expression codice_43 can be interpreted as codice_44. The alternative expression codice_45 raises an error because codice_38 is not an L-value expression, i.e. it has an R-value but not an L-value  where to store the R-value of codice_47. The right-associativity of the codice_48 operator allows expressions such as codice_49 to be interpreted as codice_43. In C++, the assignment codice_38 is an expression that evaluates to the same value as the expression codice_40, with the side effect of storing the R-value of codice_39 into the L-value of codice_40. Therefore the expression codice_43 can still be interpreted as codice_44. And the alternative expression codice_45 can be interpreted as codice_58 instead of raising an error. The right-associativity of the codice_48 operator allows expressions such as codice_49 to be interpreted  as codice_43. Non-associative operators. Non-associative operators are operators that have no defined behavior when used in sequence in an expression. In Prolog the infix operator codice_62 is non-associative because constructs such as "codice_63" constitute syntax errors. Another possibility is that sequences of certain operators are interpreted in some other way, which cannot be expressed as associativity. This generally means that syntactically, there is a special rule for sequences of these operations, and semantically the behavior is different. A good example is in Python, which has several such constructs. Since assignments are statements, not operations, the assignment  operator does not have a value and is not associative. Chained assignment is instead implemented by having a grammar rule for sequences of assignments codice_49, which are then assigned left-to-right. Further, combinations of assignment and augmented assignment, like codice_65 are not legal in Python, though they are legal C. Another example are comparison operators, such as codice_66, codice_67, and codice_68. A chained comparison like codice_69 is interpreted as codice_70, not equivalent to either codice_71 or codice_72.