Root cause: sf-letrec returns a thunk (for TCO) but the CEK dispatch
wrapped it as a value without evaluating. The thunk leaked as the
return value of letrec expressions, breaking sx-parse and any function
using letrec.
Fix: step-sf-letrec unwraps the thunk into a CEK state, so the last
letrec body expression is properly evaluated by the CEK machine.
Also:
- compile-letrec: two-phase (nil-init then assign) for mutual recursion
- Skip JIT for inner functions (closure.bindings != globals) in both
vm_call and JIT hook
- vm-reset-fn for sx-parse removed (no longer needed)
- Parser regression test: letrec with mutable pos + recursive sublists
Test results: JS 943/17, OCaml 955/0, Python 747/0
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tests: parse "(a (b) (c))" must produce 3 siblings, not nested.
Catches JIT compilation bug where closing parens cause sibling
lists to become children.
Reset sx-parse to CEK on the OCaml kernel — the JIT-compiled
version of sx-parse's complex letrec produces wrong bytecode.
CEK interpretation works correctly (tests pass on all platforms).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fix type-union assertion: use equal? for deep list comparison
- Fix check-component-effects test: define components in local env
so check function can find them (test-env returns base env copy)
- Fix parser test paren balance (agent-generated file had extra parens)
- Add apply primitive to test harness
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New test files expose fundamental evaluator issues:
- define doesn't create self-referencing closures (13 failures)
- let doesn't isolate scope from parent env (2 failures)
- set! doesn't walk scope chain for closed-over vars (3 failures)
- Component calls return kwargs object instead of evaluating body (10 failures)
485/516 passing (94%). Parser tests: 100% pass. Macro tests: 96% pass.
These failures map the exact work needed for tree-walk removal.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
