Finding
The interrogative words are unassignable, and an attempt to assign one is discarded silently by the runtime. The program runs to completion with rc=0 and the assignment simply did not happen.
Reproduction
v0.38.0, release build at 078e759.
what is 42
print of "still alive"
count is 1
where is count
print of (str of count)
rc=0, no diagnostic on stderr.
Lint does catch it:
$ eigenscript --lint --json soft.eigs
[{"code":"W019","severity":"warning","line":1,...,"message":"'what is ...' is an interrogative (question words cannot be assigned with 'is')..."},
{"code":"W019","severity":"warning","line":4,...}]
Why the runtime should not be silent here
llms.txt:78-80 already names this as a trap, and W019's message is good. But the runtime's own error policy makes this the odd one out:
- An unresolved name is a fatal runtime error (
LANGUAGE_CONTRACT.md:176).
- A type-mismatched operator raises. A non-integer index raises. A length-mismatched destructure raises. A parse error in a loaded file raises rather than executing a partial AST.
break / continue outside a loop are compile errors.
Against that, what is 42 — a statement whose entire effect is discarded — producing nothing at all is inconsistent. where is count as a bare statement is the same shape: it evaluates an interrogative and drops the result.
The affected identifiers are six ordinary English words (what who when where why how) plus prev and at. what, where, and when in particular are plausible variable names in exactly the domains this language targets — a state machine with a what, a log record with a when. The failure is not that the name is rejected; it is that it is accepted and then ignored.
Suggested fix
Make a soft-keyword assignment a compile error, with W019's message as the error text. The compiler already distinguishes the interrogative form from an assignment (that is how W019 is computed), so this should be a matter of routing the same detection to an error rather than a warning.
If a hard error is judged too breaking for a soft keyword, a runtime warning on the discarded assignment (the same channel division-by-zero uses) would at least make it visible without changing the parse.
Related: W019 in src/lint.c, llms.txt:73-80.
Finding
The interrogative words are unassignable, and an attempt to assign one is discarded silently by the runtime. The program runs to completion with rc=0 and the assignment simply did not happen.
Reproduction
v0.38.0, release build at
078e759.rc=0, no diagnostic on stderr.
Lint does catch it:
Why the runtime should not be silent here
llms.txt:78-80already names this as a trap, and W019's message is good. But the runtime's own error policy makes this the odd one out:LANGUAGE_CONTRACT.md:176).break/continueoutside a loop are compile errors.Against that,
what is 42— a statement whose entire effect is discarded — producing nothing at all is inconsistent.where is countas a bare statement is the same shape: it evaluates an interrogative and drops the result.The affected identifiers are six ordinary English words (
what who when where why how) plusprevandat.what,where, andwhenin particular are plausible variable names in exactly the domains this language targets — a state machine with awhat, a log record with awhen. The failure is not that the name is rejected; it is that it is accepted and then ignored.Suggested fix
Make a soft-keyword assignment a compile error, with W019's message as the error text. The compiler already distinguishes the interrogative form from an assignment (that is how W019 is computed), so this should be a matter of routing the same detection to an error rather than a warning.
If a hard error is judged too breaking for a soft keyword, a runtime warning on the discarded assignment (the same channel division-by-zero uses) would at least make it visible without changing the parse.
Related: W019 in
src/lint.c,llms.txt:73-80.