---

3.12.3 Ambiguous Operators Sets

The expression parser is ill equiped to deal with ambiguous operators sets and will produce undefined results when parsing expressions for such sets. Yet, ambiguous operators sets should be avoided anyhow: if they confuse the parser they’ll confuse the user as well.

The expression parser is a greedy one: it takes the longest match, it does not track back. The subexpression types are resolved after the operator parsing, the operator types are resolved as subexpressions are constructed and typed.

For the simple nature of the operator resolution, it becomes required that operators of the same name match in most of their properties.

Rules to create sound operators sets include:

• Operators with the same name should have the same priority.
• Operators with the same priority should have the same associativity.
• Unary operators should not match the priority of binary operators.
• Binary operators with the same infix name should match in their *fix syntax (infix or infix-postfix).

  See Binary Operator Syntax.

• Sequences of operators should not concatenate to the same string unless their constituents match in number and name (the ‘%%’, ‘%%&’, ‘&&’ and ‘&&&’ set is a bad example – as ‘%%&&&’ can be one of two things).
• Operators with the same name and arity should be in the same side effects category.

  See Side Effects Operators.

Not a non ambiguous operator set rule, but a general operator definition rule: the highest precedence (and lowest struct x1f4_operator_type priority value) is 128 and it is reserved for binary (and ternary component) operators associating left to right. All unary operator definitions are to have their priority set to 136.

See struct x1f4_operator_type.