JosephFerano/flan
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Invert it: the compiler moves into the program, beside the server already there

Browse Source
This commit is contained in:
Joseph Ferano 2026-09-12 17:31:44 +07:00
parent b49160b887
commit e6b49b7682
1 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
DISCUSS.md
View File

@ -428,5 +428,27 @@ the 4K result cap and its seqlock; the snapshot machinery and its generation sta
design for locals and globals; the inspector's inability to retain a value; and whether ORC or a hand-written lowering
is needed at all.
**Suggested next step:** answer the macOS main-thread question first. It is the only one of the three costs that could
**Both objections were answered by the author, and the second reframed the design — record the corrected shape.**
**Crash isolation: accepted knowingly.** Conditions already catch what the *language* signals — a failed bounds check,
an exhausted allocator, a missing file — and those keep stopping in the break loop in one process exactly as they do
now. What they cannot catch is a real memory fault: a bad pointer through the FFI, a use-after-free in an arena. That
is an OS signal, not a condition, and it takes the image with it. Same deal every Lisp makes.
**macOS: invert the relationship, and this is the right shape rather than a workaround.** Not "load the program into
the daemon" as sketched above — the opposite. **The agent is already a server running inside the program.** So the
compiler moves *into the program's process*, beside the listener that is already there. The game starts, takes the
main thread for its window, and the compiler and listener run on a side thread. That is SLIME's model: you start the
image, it serves, the editor connects.
This also fits a distinction `plan.org` already draws — dev and release builds are deliberately different. A dev build
links the compiler in; a release build ships neither compiler nor server. The same split SBCL has between a
development image and a delivered executable.
One thing that gets *better* rather than merely cheaper: a break loop in the same process as the compiler can offer
restarts that recompile and retry, with no transport in between.
**Suggested next step:** the macOS question is answered, so start instead with what it costs to link the OCaml compiler
into a dev build — the OCaml runtime and the game sharing an address space, signal handling for the break loop, and the
GC running while game code holds raw pointers into its own arenas. It is the only one of the three costs that could
make the whole idea non-portable, and it is answerable by reading raylib and GLFW rather than by building anything.