cljw nrepl and cljw -e disagree on a top-level do that requires before it uses

[BuddhiLW]

cljw -e and cljw nrepl disagree on a top-level do that requires before it uses.

Repro

$ cljw -e "(do (require '[clojure.string :as s]) (s/upper-case \"ok\"))"
"OK"

Same code over nREPL:

$ cljw nrepl --port 7931 -cp src
# eval (do (require '[clojure.string :as s]) (s/upper-case "ok"))
Name error at <nrepl>:1:39
  No namespace: 's'

  1 | (do (require '[clojure.string :as s]) (s/upper-case "ok"))
                                              ^--- No namespace: 's'

JVM Clojure and cljrs both return "OK", and so does cljw -e. Only the nREPL path fails, so this is not the language semantics, it is the two entry points evaluating differently.

Why it matters

This is the shape editor tooling sends. Our MCP layer spawns cljw nrepl for CIDER-style sessions, and a client that wraps a require and its first use in one do (a very common way to send a region) gets a name error that does not reproduce from the CLI. The workaround is to split into two separate top-level evals, which is fine once you know, and mystifying until you do.

Where I would look

src/app/eval_session.zig evalSource reads and evaluates form by form, and the -e path goes through it. Whatever the nREPL eval op uses appears to analyse the whole form before running any of it, so the alias created by the require is not visible to the analyser when it reaches s/upper-case in the same form.

I have not written a fix, since the right shape depends on whether nREPL should route through evalSource or whether the analyser should defer alias resolution. Say which you would prefer and I will send a PR.

Measured on faa1bd90 (ReleaseFast). Filing here since issues are disabled on the repo.

[BuddhiLW]

Found the cause and implemented a fix. Branch, since PRs are closed on this repo:

https://github.com/BuddhiLW/ClojureWasm/tree/fix/nrepl-toplevel-do

Cause

My first read of this was wrong. It is not that nREPL takes a different eval path from -e: it is that D-374's top-level-do unroll never reached the shared engine.

runner.runSource (script / -e) calls driver.evalTopLevelForm, which recurses through topLevelDoChildren so each child of a top-level (do …) is analysed and evaluated in sequence. eval_session.evalSource called analyzer.analyze on the whole form instead. So the use site was analysed before the require beside it had run.

evalSource backs BOTH the nREPL eval op and cljw repl, so the REPL had it too:

$ printf '(do (require (quote [clojure.set :as st])) (st/union #{1} #{2}))\n' | cljw repl
user=> Name error ... No namespace: 'st'

evalTopLevelForm's own docstring already claims -e/REPL coverage, so this reads as the function simply never being wired into the shared engine rather than a decision anyone made.

Fix

evalSource's loop body becomes a call to driver.evalTopLevelForm. It brackets analysis per leaf (D-430) rather than per source form, which is what an unrolled do wants, so the duplicated beginAnalysis/endAnalysisPersist bracket and its two now-unused imports come out. Net -10 lines.

Tests

test/e2e/phase14_nrepl_toplevel_do.sh, registered in run_all.sh next to the other nrepl steps. Five cases over bencode:

PASS nrepl_do_bundled_require -> "OK"
PASS nrepl_do_project_require -> 42
PASS nrepl_nested_do -> #{1 2}
PASS nrepl_do_returns_last -> 3
PASS e_flag_do_still_works -> "OK"

The last one pins the path that was already correct, since the fix moves shared code underneath it.

Verified as a real net: with src/app/eval_session.zig reverted to its pre-fix state and the binary rebuilt, case 1 fails; restored, all 5 pass.

bash test/run_all.sh --smoke e2e_phase14_nrepl_toplevel_do is green (11 steps, 0 failures) including both zig_build_test_tree_walk and zig_build_test_vm, so the F-012 diff oracle and the 4347-case corpus are covered.

Measured on faa1bd90, ReleaseSafe.

[chaploud]

Thanks — and your second read was the right one: this was never two eval paths, it was evalTopLevelForm not being wired into the shared engine. Your fix is on main as-is, authorship preserved: 74db35d0

Your report also turned up a fourth entry point neither of us had tested: cljw build carried its own analyze-then-eval loop in two places, so a script with a top-level do failed to compile — and the AOT half of it meant a bundled .clj compiled with different state evolution than loading the same file from source gives it. driver.topLevelLeaves now expresses the unroll for the paths that must also compile each leaf to its own chunk; evalTopLevelForm keeps its recursion for the paths that only evaluate. Both anchor on topLevelDoChildren, so what counts as a top-level do is defined once. fd5f0449

The thing your two reports have in common is a class: a shared-engine capability that some entry point does not reach. It is invisible to per-entry-point tests, because each suite passes — what is wrong is that they disagree. So there is now a differential oracle for it (test/e2e/entrypoint_eval_parity.sh), in the shape of the dual-backend one the unit tests carry: 8 programs run through -e, a script file, stdin, repl, nrepl, and build+run, and all six must agree, with no expected values written down. Verified as a real net — with your source change reverted it fails and names repl as the odd one out.

One thing you should know, since you are building on this: as of today the README says ClojureWasm is no longer maintained. A from-scratch Clojure runtime turned out to be more than one person can sustain. That is not a reaction to anything in these threads — the opposite, if anything: three precise reports with working fixes in two days is the best send-off I could have asked for, and it is why these landed rather than sat. The code stays up under EPL-2.0.