Say why an expression could not be evaluated

[DavidSagan]

A failed expression reported only that it failed:

controller 'oo' variable 'vv': could not evaluate '-1.00000000000000000E+000 / C_LIGHT'

leaving the reader to find the bad symbol themselves — hardest to do on the long expressions a translator emits. It now says which symbol and how to spell it:

controller 'oo' variable 'vv': could not evaluate '-1.00000000000000000E+000 / C_LIGHT'
  -- unknown constant or variable 'C_LIGHT'; did you mean 'c_light'?

What changed

ParseError was an empty struct thrown from fourteen places in the evaluator, so every failure arrived at the caller as an undifferentiated "not evaluable". It now carries a why, and each throw site fills it in: unknown constant/variable, unknown function, unknown species, a mass number missing its #, wrong argument count (named against the function rather than reported as an unknown name), missing ), trailing text, and a non-finite result. EvalOutcome gained an error field to carry it out.

pals_expand.cpp appends the reason after -- at the four sites that report an expression failure: element values (substitute_values), controller initial values, controller control expressions, and set command values. Controller variables needed a field on CtrlVar, since the report happens in a later pass than the evaluation.

Suggestions without a second table

Every built-in constant is lower case, so case_hint lowers the name and retries builtin_constant and the user symbol table — no list to drift out of step, and it also catches a user constant written MY_CONST but defined my_const. Function names live only in apply's dispatch chain, so the lowered spelling is probed there and the result discarded: a miscased function is still an error, not a silent correction, and the recursion terminates because a lowered name lowers to itself.

Tests

Two cases in test_expressions.cpp: the element path (miscased constant with suggestion, an unknown name that gets no invented suggestion, miscased function, arity, unknown species, missing #, unbalanced parens) and the controller path. Full suite: 1181 assertions in 227 cases.

Not in this PR

• A variable whose initial value fails now cascades into a second message that blames the variable (unknown constant or variable 'vv') though it is declared and merely valueless. Fixing that means the controller pass telling the evaluator "declared but unevaluated"; the shortcut of defaulting a failed variable to zero would turn a loud error into a silently wrong number.
• The C entry point evaluate_pals_expression(expr, ok) still reports only a boolean, so PALSJulia raises with the text alone. Widening it is an ABI change.

🤖 Generated with Claude Code