# F-06 — expressionParser.js: Capable Pratt parser is nearly unused outside documentFacts

**Severity:** Observation  
**File:** `core/src/ast/expressionParser.js` (caller audit)  
**Category:** Underused infrastructure; validators reinvent what it provides  
**Remediation appropriate:** Yes — integrated with F-01, F-02, F-04 fixes

---

## Context

`expressionParser.js` is a full Pratt parser that converts a `TokenSpan` into a typed expression
tree (`ExprNode`). It handles: literals, identifiers, binary operators (with precedence), unary
operators, function calls, parenthesised expressions. It infers types for literals
(`AcurityTypes.STRING`, `DOUBLE`, `SHORT`, `LONG`, `BIGINT`, `BOOLEAN`).

This is non-trivial infrastructure, correctly implemented, with complete operator precedence.

---

## Current usage

Grepping the codebase for `parseExpression` callers:

| Caller | Usage |
|---|---|
| `typeValidator.js` | Calls `parseExpression` on assignment values for type inference |
| `argumentTypeValidator.js` | Calls `parseExpression` on function call arguments |
| `doIteratorValidator.js` | Calls `parseExpression` on DO iterator bounds |
| `exitStatementValidator.js` | Calls `parseExpression` on EXIT condition |

These validators are correctly using the expression parser. They are the good examples.

---

## Validators that should be using it but are not

| Validator | Where expression parsing would help |
|---|---|
| `returnTypeValidator.js` | Type inference in `inferReturnExpressionType` (regex reimplementation) — see F-02 |
| `variableValidator.js` | `getParamModeVariables()` — regex to identify function call and extract args — see F-01 |
| `functionValidator.js` | `validateCodeSnippet()` — regex scan for `name(` patterns — see F-04 |

---

## A note on the TokenSpan interface

The expression parser takes a `TokenSpan` — the `.value` field of `SetStatement`, `AssignStatement`,
`ReturnStatement`, etc. These TokenSpans are already in the AST as part of normal statement nodes.
The validators that don't use the expression parser are also the ones that don't use the AST for
their statement nodes (they use `parseAssignment()`, `RETURN_RE`, etc. instead).

This creates a natural dependency chain: **to use the expression parser, a validator first needs
access to the AST node's TokenSpan**. Fixing F-01 and F-02 (accessing statement nodes from the
AST) automatically enables the expression parser for those validators.

---

## Positive observation

The validators that DO use the expression parser (`typeValidator`, `argumentTypeValidator`,
`doIteratorValidator`, `exitStatementValidator`) represent the fully-migrated pattern:
1. Get statement from AST (e.g. `DoStatement.iterator.start`)
2. Pass its TokenSpan to `parseExpression(span)`
3. Work with the ExprNode tree

These validators have no regex on expression text and produce accurate column positions from
the token `char` fields.

**These files are the reference implementation pattern** for all future validator work that
needs to inspect expression content.

---

## Recommendation

No standalone action for this finding — it is resolved as a consequence of F-01, F-02, F-04.
Document this in the migration guide (see TRACKER item) so future validators written against
this codebase know to use `parseExpression` rather than regex on expression strings.
