`store x as my_action with a and b` silently mis-parses as concatenation/logical-and instead of an action call (needs `call`)

[logbie]

Summary

Calling a user-defined action in expression position without the call keyword does not call the action — the expression parses as with-concatenation of the action value plus a logical and chain of the intended arguments — and the program runs anyway, producing garbage output. The only diagnostic is a non-fatal typechecker warning, so the failure is easy to ship.

Minimal reproduction

define action called build_reply with parameters user_text and model_id and via_text:
    return "hello " with user_text
end action

store reply_text as build_reply with "world" and "m1" and "t1"
display reply_text

Actual output:

action build_replyyes

That is: build_reply stringifies as action build_reply, then with concatenates the result of "world" and "m1" and "t1" evaluated as logical And (truthy → yes). The typechecker does warn —

error[ERROR]: Cannot perform logical And on Boolean and Text - Expected Boolean but found Text

— but the program still executes (warnings are non-fatal), so in a server context this surfaced as a chatbot streaming the literal reply "action build_replyyes" to the browser.

The working form is store reply_text as call build_reply with "world" and "m1" and "t1" (as used in TestPrograms/action_overloading_comprehensive.wfl).

Why this matters

Principle 4 (clear, actionable errors) and the No-Unlearning Invariant: add with 5 and 3-style call syntax appears in learning materials, and the statement form call name with args teaches that with introduces arguments — so store x as name with args is exactly what a beginner writes. Getting a silently-wrong value with only a type warning (whose message points at and, not at the missing call) is a trap.

Environment

• wfl 26.7.52, built from source at ed704e6 (current main), rustc 1.94.1, Linux

Suggested improvements (any of)

1. When an expression's leading identifier resolves to an action and is followed by with, either parse it as a call, or
2. make it a hard parse/analyze error ("build_reply is an action — did you mean call build_reply with ...?"), or
3. at minimum, special-case the typechecker diagnostic to suggest the missing call when the left operand of the offending with/and chain is an action value.

[logbie]

Triage: CONFIRMED, and this is a severity-calibration bug as much as a parser one.

Verified against main at 69c1c1e (v26.7.53). Your diagnosis holds end to end:

• action build_reply is the Display impl for a function value — src/interpreter/value.rs:558, write!(f, "action {}", ...).
• with in expression position builds Expression::Concatenation (src/parser/expr/binary.rs:477), so the action value stringifies and the and chain collapses to a truthy yes. Output action build_replyyes is exactly what those two rules produce.
• No "did you mean call" hint exists anywhere in src/ — I grepped for it; suggestion 3 is entirely unimplemented.

The reason this ships is the fatality asymmetry, and it is worth naming explicitly. In src/main.rs:

• analyzer diagnostics → has_fatal_errors → process::exit(3) (line 897)
• typechecker diagnostics → printed under the header "Type checking warnings:" and execution continues (lines 903-950; only TypeCheckError::Budget is fatal)

So the only signal for a silently-wrong program is a non-fatal warning that is rendered as error[ERROR] — which trains people to ignore something labelled "error". Meanwhile #647 is the mirror image: a working runtime feature killed by a fatal analyzer error. The two together suggest the severity model needs a pass, not just a special case.

Recommended shape (option 2, with 3 as the fallback):

1. Prefer the hard error over silent reinterpretation. When the leading identifier of an expression resolves to an action and is followed by with, emit an analyzer-level (fatal) error: ```build_replyis an action — did you meancall build_reply with ...`?``. The analyzer already carries `Type::Function` symbols (`src/analyzer/mod.rs:3341`, `:3910`), so the resolution needed is in hand.
2. Do not auto-parse it as a call (your option 1) without a deprecation cycle. store x as some_action is legal today for taking an action reference, and alias_call_target (src/analyzer/mod.rs:4805+) depends on that. Silently promoting name with args to a call changes the meaning of currently-valid programs — the No-Unlearning Invariant cuts against it, and backward compatibility is the repo's hard rule.
3. If a hard error is judged too aggressive for a first pass, at minimum special-case the diagnostic so it points at the missing call rather than at and — but that leaves the wrong program running, which is the actual harm you hit in the Rin server.

TDD note: the red test wants to be an analyzer/typechecker assertion on the diagnostic and its severity, plus a TestPrograms/ case proving the reference form store h as my_action still works, so the fix cannot over-reach.

Suggested labels: bug, parser, analyzer, diagnostics, dx.

Posted by the WFL repo warden (automated triage pass).