Unknown functions are only detected at evaluation time, not at parse time

[MidnightDesign]

When a call carries an inline return type, the parser accepts any function name. The error only surfaces at evaluation time.

Reproduction

$expr = ExpressionParser::parse('xs:list<int>.sum:int()');   // parses fine
$expr->evaluate(new Scope(['xs' => [1, 2, 3]]));
// EvaluationError: Unknown function "sum"

Same for .reduce:int(...), .length:int(), .first:int() — every plausible-but-nonexistent name.

Why it matters

Expressions are typically parsed and validated once (e.g. when a user saves one) and evaluated much later, in a different context. A name typo therefore escapes validation and only explodes at evaluation time, where it is far more expensive to handle.

Suggestion

When a Declarations instance is available, the parser already knows the built-ins plus any custom declared functions. An undeclared function name could be rejected at parse time instead of being deferred to Scope.

[MidnightDesign]

Why this can't be fixed cleanly yet: it's blocked on generics

Digging into this, the root blocker is the parser's escape hatch: a call that carries an inline return type but no declaration is accepted, using the inline type as the return type and skipping argument checks. That single rule is what lets sum:int() through — and it can't simply be tightened.

Why the escape hatch is load-bearing

The library's own built-ins map, filter, head, tail, and unwrap have no declared signature (they can't be expressed without generics), so they rely on the exact same escape hatch that sum:int() does. The parser can't tell a typo apart from a real-but-undeclared function.

Why "reject unknown names" breaks BC

Classifying every currently-parsing call by whether it evaluates cleanly in some scope:

Case	Today	If the parser rejected unknown names
Built-in call (map, substr, …)	works	still parses (known) — fine
Declared custom call	works	still parses (declared) — fine
Undeclared + inline type, impl in Scope (e.g. mask)	works	rejected at parse — BC break
Undeclared + inline type, no impl (sum)	always eval-errors	rejected at parse — not a break, same failure earlier

sum:int() itself is safe to reject (it never evaluates). But the parser can't distinguish it from an undeclared consumer function that is backed by a Scope implementation — both are just "undeclared name + inline type", and the Scope isn't known until evaluation. Rejecting the class rejects the working case too.

Why not an opt-in flag now

An opt-in strict mode would work, but generics will reshape this whole area (all built-ins become declarable, and a properly-typed migration path opens up). A flag added now would be permanent API surface that would likely look wrong afterward. Not worth it.

Sequencing

1. Generics — lets every built-in be declared, so the escape hatch stops being load-bearing.
2. Then the parse-time validation can land cleanly. Note that even post-generics, a default-on rejection still breaks path (b) above (undeclared consumer functions used with only an inline type), so the final step is still BC-sensitive — best done as a deprecation at a major version, or as an explicit opt-in.

Generics is a hard prerequisite, not a nice-to-have, for this.

Orthogonal note: the built-in list has drifted

Independent of the above, the set of built-in functions is duplicated and out of sync across three places:

• Declarations::functions (parse-time) knows 7: contains, count, isSome, some, substr, take, unique
• Scope (eval-time) implements 12: the 7 above plus filter, head, map, tail, unwrap
• the README documents 10 (missing filter and unwrap)

Unifying these into a single source of truth is additive, carries no BC break, and is a prerequisite for the eventual validation anyway. Tracking that as a separate cleanup.