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

Where the next session starts, and what to read first

Browse Source
This commit is contained in:
Joseph Ferano 2026-09-12 17:46:05 +07:00
parent fbc4aea071
commit 4ea089839c
2 changed files with 33 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
DISCUSS.md
View File

@ -386,6 +386,29 @@ object cache separately at `Build.cachedir ()`, stable across builds. Nothing sw
`dlclose`d, so a long session accumulates both files and mappings. Sweeping at session end is cheap and unrelated to `dlclose`d, so a long session accumulates both files and mappings. Sweeping at session end is cheap and unrelated to
any of the above. any of the above.
## NEXT SESSION STARTS HERE
**The agreed plan: investigate putting the compiler inside the running program.**
Today there are two programs. The *daemon* is the compiler. The *game* is a separate program it launches. They talk
over a socket, so everything the editor shows — locals, globals, the stack, evaluation results — has to be packed up
in one program, sent across, and unpacked in the other. A large share of what `BUILT.md` documents exists only to move
data between those two address spaces.
Putting the compiler inside the game removes all of that. There is nothing to send, because the compiler can read the
program's memory directly. It is what SBCL does, and it is why interactive work in SBCL is instant.
**Read, in this order:** item 13 (what is actually being decided, and why the order matters), then item 11 (the shape,
the two objections and how the author answered them), then item 12 (the specific questions a spike must answer).
**First task, and it is research not building:** the spike in item 12 — what it costs to link the OCaml compiler into
a dev build. OCaml 5.2's multicore runtime has already removed the objection that would have been fatal. If it embeds
acceptably, everything else is reachable.
**Do not start with the backend question.** Merge first, measure, then choose. Item 13 says why.
---
## 11. One process, not two — the biggest open question ## 11. One process, not two — the biggest open question
Raised at the very end of the session and **not resolved**. It subsumes items 9 and 10, and possibly several decisions Raised at the very end of the session and **not resolved**. It subsumes items 9 and 10, and possibly several decisions

10
NEXT.md
View File

@ -480,6 +480,16 @@ acquisitions against releases at that boundary and report what is still held at
annotation, nothing running at a distance — it does not change how code is written, it reports when something was annotation, nothing running at a distance — it does not change how code is written, it reports when something was
forgotten. forgotten.
## Before the batch below: read `DISCUSS.md`'s "NEXT SESSION STARTS HERE"
An architectural question was raised at the end of 2026-09-12 and agreed as the next thing to investigate: **putting
the compiler inside the running program's process, instead of the two separate processes there are today.** It may
reopen several things recorded here as settled — the watch design, the 4K result cap and its seqlock, the snapshot
machinery, the render-thunk-per-inspection design for locals and globals, and whether an in-process JIT or a
hand-written backend is needed at all.
It is research first, not building. The batch below stays valid and none of it is blocked by the question.
## The next batch, in order ## The next batch, in order
Agreed at the end of 2026-09-12. Ordered by priority, not by size. Items 1-3 and 5-6 want the compiler core and should Agreed at the end of 2026-09-12. Ordered by priority, not by size. Items 1-3 and 5-6 want the compiler core and should