Hosting KidLisp on Clojure / ClojureScript#

Date: 2026-04-17 Author: Claude (for @jeffrey) Scope: Feasibility assessment of moving the KidLisp runtime from hand-rolled JS to a Clojure/ClojureScript host, plus the state of Clojure → WASM as of early 2026.

TL;DR#

Not recommended as a wholesale migration. ClojureScript is a natural Lisp host in principle, but KidLisp's specific surface area — bespoke reader syntax, tight coupling to the Aesthetic Computer Disk API, and an expectation of ~instant boot inside an already-large web runtime — makes a rewrite costly while delivering modest linguistic upside. The most defensible path, if Clojure appeals for other reasons, is a compile-time target (KidLisp AST → ClojureScript forms) rather than a runtime port. Clojure on WASM in 2026 is still pre-production across the board; nothing on that track is ready to replace a shipping JS runtime.

1. What KidLisp actually is today#

• system/public/aesthetic.computer/lib/kidlisp.mjs — ~15,400 lines of hand-written ES modules: reader, evaluator, effect dispatch, and timing DSL all in one.
• 118 built-in functions across 12 categories (drawing, audio, math, control, animation, data, etc.).
• Extra ports already exist outside the browser runtime:
  • kidlisp-gameboy/ — KidLisp → GBDK/C compiler for Game Boy.
  • kidlisp-n64/ — bare-metal / libdragon experiments.
• Integrated with the JS-native Disk API (lib/disk.mjs) via destructured function bags ({ wipe, ink, line, ... }) — effects are immediate-mode calls into canvas/WebGL/audio graph.
• Non-standard Lisp features that matter for any host decision:
  • Timing literals: 1s, 2s..., 0.5s!.
  • Cached-code references: $abc123, (embed $code ...).
  • Handle/timestamp references: @user/123456.
  • Unquoted URLs in arg position: (paste https://example.com/a.png x y).
  • Dynamic color atoms: rainbow, zebra, c0..c150.
  • Reader-visible dashes are subtraction, not identifier chars.

These extensions mean KidLisp is only approximately a Lisp at the reader level. Any host — Clojure included — would need a custom reader, so "it's already a Lisp" is a weaker argument than it first appears.

2. Why ClojureScript looks tempting#

• Homoiconicity. KidLisp ASTs map cleanly onto clojure.core sequences and symbols.
• Macros. Timing (1s, 2s...), (once ...), (later ...) all read like macro fodder — ClojureScript macros would give them a first-class home instead of special-cased evaluator branches.
• Persistent data structures for free, plus proper recur/trampolines for the repeat/bunch loops.
• REPL-driven iteration. shadow-cljs + reagent-style hot reload is culturally aligned with "tweak a number, keep the canvas" — which is exactly what REPORT-kidlisp-realtime-state.md says KidLisp still doesn't do well.
• Compiler infrastructure. Google Closure's advanced optimizations, dead-code elimination, and source maps are mature.
• Shared language across hosts. In principle one ClojureScript codebase could target browser (cljs), native (jank/GraalVM), and JVM simultaneously — appealing for the Game Boy / N64 / OS targets already in the repo.

3. Why it's the wrong move for KidLisp specifically#

3.1 Bundle and boot cost#

• A minimal self-hosted ClojureScript runtime (for runtime eval of user code — which KidLisp must do) brings in cljs.js + the analyzer + the reader: ~1–2 MB gzipped in practice, even after advanced optimizations, because you cannot DCE a runtime evaluator.
• Scittle / SCI is smaller (~300–500 KB gzipped) but is an interpreter with different perf characteristics than the present kidlisp evaluator.
• The current kidlisp.mjs ships as part of Disk; its footprint is already accounted for and tree-shakes against the rest of the runtime. A CLJS host would add weight on top of disk.mjs (572 KB) rather than replacing anything JS-shaped.
• Aesthetic Computer is mobile-first; a cold-start regression of even 500 ms on low-end devices would be felt immediately.

3.2 Reader is not reusable#

• Clojure's reader cannot parse 2s..., 0.5s!, $abc123, @user/123456, or bare URLs.
• You'd still write a custom reader. At that point, "ClojureScript is a Lisp" buys you data structures and macros but not parsing.
• Worse: you must teach editor/LSP/formatter tooling that these literals exist, or give them up. The existing kidlisp-reference.mjs is already a docs-first contract; splitting it across Clojure reader + custom reader risks drift.

3.3 Effect boundary friction#

• KidLisp calls are side effects on a JS graphics/audio API designed around destructuring ({ wipe, ink, paste }). ClojureScript interop with that shape is verbose ((.wipe api) / (js/api.wipe)) unless you wrap everything, and then you're maintaining two APIs.
• The Disk API changes often (see disk.mjs churn). Every change becomes a double-edit: JS definition + CLJS wrapper.

3.4 Ecosystem/ops mismatch#

• The rest of AC is .mjs: boot, bios, disk, session server, netlify functions, lith deploy. Introducing a ClojureScript build chain (shadow-cljs, deps.edn, JVM on the build box) fights the current fish-based single-toolchain ethos.
• lith (DO VPS) deploys pull from the tangled knot and run Node. Adding a JVM-class dep to the deploy pipeline is a real cost.

3.5 Existing external ports regress#

• kidlisp-gameboy compiles KidLisp → C for GBDK. A ClojureScript-hosted evaluator doesn't help this path (still need a bespoke compiler).
• kidlisp-n64 is assembly-adjacent. Same story.
• If anything, the Game Boy and N64 work suggests KidLisp's semantic model is the stable asset and the evaluator language is incidental — which argues for keeping the evaluator where its neighbors live (JS in the browser, C on GB, asm on N64), not centralizing on Clojure.

4. State of Clojure → WASM (early 2026)#

Nothing in this space is production-ready for replacing a shipping web runtime. Summary of the tracks:

4.1 jank (LLVM-native Clojure)#

• Native Clojure dialect by Jeaye Wilkerson, targets LLVM IR → native binaries.
• LLVM's wasm32 backend is mature, so in principle jank can emit WASM. In practice, the Clojure runtime (persistent collections, keywords, vars, multimethods) ships as a C++ runtime library that has to be built for the target; the WASM build path has been "experimental / pre-alpha" through 2025 and into early 2026.
• Not a credible host for a browser interpreter today. Would also need AOT — jank doesn't give you in-browser eval out of the box.

4.2 GraalVM native-image → WASM#

• Oracle's GraalVM has an experimental WebAssembly backend (native-image --tool:wasm / Truffle-on-WASM variants). Works for tiny programs; Clojure pulls in a large JVM surface and hits UnsupportedFeatureError on real-world code regularly.
• Babashka (GraalVM + SCI) demonstrates Clojure can AOT to a native binary, but Babashka's own maintainers have not committed to WASM as a shipping target.
• Use case fit: poor for a browser runtime. Size would dwarf the current evaluator.

4.3 SCI / Scittle (pure JS, not WASM)#

• Small Clojure Interpreter by @borkdude. Runs in the browser today as plain JS (~300–500 KB gz).
• Not a WASM port — it's JS. Often miscategorized in WASM discussions.
• Could theoretically be embedded inside a QuickJS-WASM sandbox, but that's stacking interpreters and helps nobody.

4.4 ClojureScript via JS → WASM glue (e.g. Javy, Spin, Kotlin/JS-WASM paths)#

• Tools like Javy (Shopify) and Spin/Wasmtime embed JS engines inside WASM. You can run ClojureScript-compiled JS inside a WASM-embedded JS engine. That doubles the interpreter layers.
• Useful for serverless edge; irrelevant for AC's browser runtime.

4.5 Ferret (Clojure → C++)#

• Ferret AOT-compiles a Clojure subset to C++. C++ → WASM via Emscripten is routine, so Ferret → WASM is feasible for small, statically-knowable programs.
• Doesn't support eval, which is the KidLisp core requirement.

4.6 Summary table#

Bottom line: if the reason to move to Clojure is to eventually run KidLisp as WASM, wait. In 2026 the realistic browser deployment of Clojure is still JavaScript (via CLJS or SCI), not WebAssembly.

5. Concrete paths forward (ordered by cost)#

1. Do nothing to the host, improve the current evaluator. The single biggest pain point identified in REPORT-kidlisp-realtime-state.md is the full-reset-on-edit behavior. That is a state-management issue, not a language-host issue. Fix it in kidlisp.mjs.

2. Adopt Clojure data without adopting the Clojure runtime. Keep the JS evaluator; borrow ideas (persistent vectors via a tiny Immer-like lib, recur-style trampolines). Cheap, keeps the bundle lean.

3. Move the KidLisp compiler (not the interpreter) to Clojure. The Game Boy and N64 ports are essentially compilers. If you want a unified compilation story, a JVM-hosted Clojure compiler that emits C / asm / JS makes sense there, because it runs at dev time, not in the user's browser. This is the highest-value place Clojure would land in AC.

4. Rewrite the browser evaluator in ClojureScript. Only if KidLisp stops being primarily a browser artifact and you commit to shadow-cljs-in-the-deploy-pipeline. Rough order: 6–12 eng-weeks to reach parity, assuming you keep a custom reader and a CLJS-shaped Disk API wrapper. Meaningful perf work on top.

5. Bet on Clojure WASM. Premature in early 2026. Revisit when jank's WASM target ships stable builds and has eval (or when an ahead-of-time model becomes acceptable for KidLisp).

6. Recommendation#

Keep the runtime in JavaScript. Invest Clojure/ClojureScript effort, if any, in the compiler tier (the place where KidLisp becomes Game Boy C, N64 asm, or native binaries) — not the browser interpreter. Do not block on Clojure WASM; the 2026 state of that ecosystem is not where a shipping creative-computing runtime should live.

Appendix: what would change my mind#

• A production-grade sci or scittle release that is clearly under 150 KB gzipped with a usable macro system.
• A decision to rebuild Aesthetic Computer's client around a JVM/GraalVM deploy story for other reasons (e.g. collapsing session-server + site onto a single JVM runtime), at which point CLJS becomes a natural front-end complement.
• jank reaching a 1.0 with a shipping WASM target and in-browser eval.
• KidLisp growing a module system / macro layer that genuinely outstrips what the hand-rolled evaluator can express — at that point a host language with real macros starts paying for itself.