Section 39: Expressions, Operators, and Evaluation Order¶

TECHSPEC-39 — Section 39 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Expression Philosophy¶

Expressions produce values, perform operations, or evaluate conditions.

The language must define expression behavior precisely so that the same source code produces consistent results across execution targets.

Evaluation order, conversions, side effects, and failures must never depend on unspecified behavior.

2. Operator Categories¶

The language supports the following operator categories:

The exact operator set may expand as the language develops.

3. Operator Precedence¶

Operator precedence determines which operations are evaluated first when parentheses are absent.

The initial proposed precedence, from highest to lowest, is:

1. Parentheses and grouped expressions.
2. Member access and indexing.
3. Unary operators: NOT, unary -, unary +.
4. Multiplication, division, remainder.
5. Addition and subtraction.
6. Comparisons.
7. Equality and inequality.
8. Logical AND.
9. Logical OR.

Rules: - Precedence must be formally defined in the language grammar or specification. - Parentheses may explicitly override normal precedence. - Ambiguous expressions must not be interpreted differently by different compiler implementations.

4. Associativity¶

Associativity determines how operators of equal precedence are grouped.

Initial rules: - Arithmetic binary operators are left-associative. - Comparison operators must not be chained unless explicitly defined. - Logical operators are left-associative. - Assignment operators are right-associative.

The compiler must reject unsupported operator combinations rather than guess their intended meaning.

5. Evaluation Order¶

Expressions must use a defined evaluation order.

Rules: - Function arguments are evaluated from left to right. - Binary expression operands are evaluated from left to right. - Collection elements are evaluated in their written order. - Assignment evaluates the target and value according to explicitly defined rules. - Side effects must occur in the specified order. - Compiler optimizations must preserve observable behavior.

No expression may depend on an unspecified evaluation order.

6. Short-Circuit Evaluation¶

Logical operators use short-circuit evaluation.

For AND: - Evaluate the left operand first. - If the left operand is FALSE, the right operand is not evaluated. - Otherwise, evaluate the right operand.

For OR: - Evaluate the left operand first. - If the left operand is TRUE, the right operand is not evaluated. - Otherwise, evaluate the right operand.

Rules: - Short-circuit behavior must be consistent across targets. - Skipped expressions must not execute side effects. - Both operands must satisfy the required Boolean type rules.

7. Type Compatibility¶

Operators must define the types they accept and produce.

Rules: - Arithmetic operators require compatible numeric types. - Comparison operators require explicitly supported comparable types. - Logical operators accept Boolean values. - No implicit numeric conversions are permitted. - Optional values and Result values must be handled explicitly. - Invalid operator/type combinations must produce compiler errors.

Numeric behavior must follow Section 21.

8. Equality and Comparison¶

Equality and comparison must have defined semantics for each supported type.

Rules: - Primitive types use their specified equality rules. - Structured types must define whether equality compares values, identity, or another documented property. - Collection equality must have explicitly defined behavior. - Floating-point or decimal special values must follow the language's numeric specification. - Equality must not silently perform conversions or normalization.

Comparison operators must reject types without a defined ordering.

9. Assignment and Mutation¶

Assignment changes a mutable variable or permitted mutable location.

Rules: - Immutable values cannot be reassigned. - Assignment must preserve the target's declared type. - Compound assignment operators must follow the same arithmetic and overflow rules as their equivalent operations. - Assignment must respect ownership and borrowing restrictions. - Mutation must respect object invariants. - Assignment failures must not leave partially updated state unless that behavior is explicitly documented.

10. Operator Overloading¶

Operator overloading may be supported for user-defined types, but it must remain restricted.

Rules: - Only explicitly supported operators may be overloaded. - Overloaded operators must have declared signatures and contracts. - Overloading must not change operator precedence or associativity. - Overloads must not silently convert unrelated types. - Side effects must be declared. - Overloads must not misrepresent the standard meaning of an operator. - Ambiguous overload resolution must produce a compiler error.

The MVP should begin with built-in operator behavior and defer user-defined overloading.

11. Expression Failures¶

Expressions may fail because of: - Numeric overflow or underflow. - Division by zero. - Invalid indexing. - Invalid conversions. - Missing optional values. - Failed function calls. - Contract violations. - Resource or external operation failures.

Rules: - Failure propagation must be explicit. - An expression must not silently substitute a default value after failure. - Failure must not be mistaken for a valid result. - Partial side effects must be documented and observable.

12. Compiler Responsibilities¶

The compiler must: - Parse expressions according to the formal grammar. - Apply precedence and associativity rules. - Enforce evaluation order. - Validate operand types. - Resolve supported overloads. - Reject ambiguous expressions. - Preserve short-circuit behavior. - Check mutation and ownership restrictions. - Preserve expression semantics during optimization and code generation.

13. Verification Limitations¶

Correct expression typing does not establish that the expression produces the intended business result.

Verification reports must distinguish: - Expression parsed successfully. - Operand types checked. - Evaluation semantics established. - Contracts checked or proven. - Runtime failures observed. - Intended behavior verified or still unknown.

14. Design Goal¶

An AI agent must never need to guess how an expression is grouped, evaluated, converted, or executed.

Expression semantics must be explicit, predictable, and consistent across every supported execution target.

Source and related sections¶

Source file: TECHSPEC-39.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.