Data Operations Gaps Between Documentation & Implementation

[Crypto2099]

Documentation lists operators that are not implemented in the grammar

Summary

The data expressions documentation documents arithmetic, comparison, logical, and ternary operators as supported features of Tx3. However, only +, -, and ! are defined in the PEG grammar (crates/tx3-lang/src/tx3.pest). All other operators fail at parse time.

Reproduction

Any of the following will produce a parse error:

// Arithmetic
locals { x: a * 2, }        // ERROR: parsing
locals { x: a / 2, }        // ERROR: parsing

// Comparison
locals { x: a == b, }       // ERROR: parsing
locals { x: a != b, }       // ERROR: parsing
locals { x: a < b, }        // ERROR: parsing
locals { x: a > b, }        // ERROR: parsing
locals { x: a <= b, }       // ERROR: parsing
locals { x: a >= b, }       // ERROR: parsing

// Logical
locals { x: a && b, }       // ERROR: parsing
locals { x: a || b, }       // ERROR: parsing

// Ternary
output { to: flag ? A : B, amount: s - fees, }  // ERROR: parsing

Error message for all cases:

Parsing error: expected [data_add, data_sub, data_property, data_index,
explicit_variant_case_constructor, implicit_variant_case_constructor]

What works

The grammar (data_expr rule) currently defines only:

Operator	Syntax	Type
Add	a + b	Infix
Subtract	a - b	Infix
Negate	!a	Prefix
Property access	a.field	Postfix
Index access	a[0]	Postfix

What the docs claim but is missing

Category	Operators	Grammar rules needed
Arithmetic	*, /	data_mul, data_div
Comparison	==, !=, <, >, <=, >=	data_eq, data_neq, data_lt, data_gt, data_lte, data_gte
Logical	&&, ||	data_and, data_or
Ternary	? :	data_ternary

Relevant code

The data_expr rule in crates/tx3-lang/src/tx3.pest (line 134) would need to be extended with new infix operators. The pratt parser setup in crates/tx3-lang/src/parsing.rs (around line 1207) would need corresponding precedence and mapping entries. New AST nodes, analysis, and lowering support would also be required for each operator.

Suggestion

Either:

1. Update the docs to reflect only the currently implemented operators, clearly marking the rest as planned/roadmap items, or
2. Implement the missing operators in the grammar, parser, analyzer, and lowering stages

A phased approach could prioritize by likely usage:

• Arithmetic: *, / — common in amount calculations
• Comparison: ==, != — needed for conditional logic
• Comparison: <, >, <=, >= — useful for validation
• Logical: &&, || — needed to combine conditions
• Ternary: ? : — conditional expressions (the docs show should_lock ? TimeLock : Receiver which is a compelling use case for output routing)