Joseph Ferano 0c523cfe8b The program can be run again, in the process that is already there
You run a program under flan dev, it opens a raylib window, you close the
window, main returns — and there is no way to get another window short of
flan-dev-restart-program, which throws away the build, the session and every
global with it. In Common Lisp or Clojure the image outlives main, so you call
it again. The process here already outlived main: the exit hook flushed, closed
stdout and sat in for (;;) pause(). Nothing could wake it.

So main() is a loop. The hook records the status and longjmps back into a
setjmp in main() — there is no return available, since flan_exit is reached
from wherever the program happened to be — and the thread waits on a condition
variable until the new rerun op signals it. The main thread is the one that
runs main again: a window belongs to the thread that opened it, and on macOS to
the first thread of the process. A longjmp pops no frame, so the park first
empties the handler stack, the restart stack and the shadow frame chain, each
of which was a chain of allocas in stack the next run is about to write over.
Nothing else is reset; the second run reads whatever the first left in the
globals, which is the semantics that was asked for.

Closing stdout had to go with it. That was how the compiler learned the program
was done, but a pipe delivers EOF once, so the signal and the program's output
were the same resource and spending it left the second run with nowhere to
print. The descriptor hazard the old code reopened /dev/null for goes away with
the close that caused it. Liveness is asked for instead, through a weak symbol
in the same style as the agent's, and is now three states rather than two: Live,
Parked and Gone. Every guard branches on that before consulting the break
state, because the agent's listener answers "running" while the program is
parked and telling somebody whose program has finished that it is running is
worse than saying nothing. Only eval accepts a parked program — it queues and
waits for nothing, and the queued module installs at the first frame boundary
of the next run, so a body can be fixed while parked and the re-run executes
it. Everything else needs a frame boundary or a stopped stack, has neither, and
says which, naming the command that gets the program back.

A re-run while the program is running is refused rather than queued: the test
and the signal happen under one mutex, so two mains writing the same globals at
once never starts.

:parked rides on every reply beside :stopped, for the reason :stopped does —
finishing is as unannounced as stopping, more so when the way it happens is a
mouse click on a title bar. Emacs shows flan:parked in the modeline and binds
flan-rerun to C-c C-M-x.
2026-09-17 19:01:01 +07:00
..

What is in here, and what is still true

These are the documents that are written once and read occasionally: the reasons behind the code, the reports from finished investigations, and the record of individual work sessions. The documents that are edited every day stay at the repository root, because source comments cite them by bare filename from dozens of places and a path that moves is a path that rots. So plan.org, NEXT.md, spec-memory.md and spec-conditions.md are one directory up, and everything here points back at them.

A note on how to read the citations below: a document in this directory that says plan.org means the one at the repository root. Nothing in docs/ is named for a file at the root, so there is no ambiguity, and rewriting a hundred prose mentions into ../plan.org would have cost more in readability than it bought in precision.

If you have thirty seconds

Read BUILT.md. It is by far the largest document here and it is the one that pays: it holds the reason behind every part of the compiler that exists, from why nothing is ever dlclosed to why the printer is a compile-time walk over a type rather than a runtime function. It is current, it is maintained, and deleting it would mean deriving all of it again. If you want to know why a thing is the shape it is, the answer is in here.

After that, ../NEXT.md at the root for what is actually in flight, and REFERENCES.md here for where the evidence comes from — the reference clones on this machine, what each one answers, and the standing rule that a claim in these notes was read out of a clone rather than recalled.

The current documents

File What it is
BUILT.md Why the parts that exist are shaped the way they are. The longest and the most load-bearing document in the repository. Current.
DISCUSS.md Open questions, raised and deliberately not answered. Nothing in it is a decision or a task; entries that have since been answered say so and point at where the answer landed. Current, though it is half archive by now.
PORTING.md What the author's game, siam-farmer, needs from Flan that Flan does not have yet, measured against the code that exists rather than against a plan. It is the requirements document the language is actually steering by. Current.
REFERENCES.md The reference clones under ~/Repositories, what each one is consulted for, and the specific files and lines already cited from them. Current.

The reports

File What it is
SPIKE-GENERICS.md Milestone 5's parametric polymorphism, run early and out of order as a spike. The spike succeeded and generics landed, so this is the report of finished work rather than a live plan — but its findings about where the cost falls are still the reason the implementation looks the way it does. Historical, findings still stand.
overview.md The first brainstorm, from before the language had S-expressions. It says in its own first line that it is superseded and no longer accurate. Kept for history only; its table of what changed is the only part worth reading. Superseded.

handoffs/

One report per work session, each written by whoever held the branch at the time. They are the operational record: what was attempted, what was measured, what was decided without being able to ask, and what was left open for the next lane. They are all historical the moment they are written — a handoff describes a session that has ended — but they are cited by name from source comments and from NEXT.md, because the reasoning behind a guard or a calling convention is often only written down once and this is where it was written.

Six of them are the hand-written x86-64 backend, read in the order the work happened: handoffs/HANDOFF-x86-rt.md set the remaining-items list that the four after it close, handoffs/HANDOFF-x86-redef.md built the redefinition emitter, handoffs/HANDOFF-x86-aggregates.md took that across the struct boundary, handoffs/HANDOFF-x86-guards.md settled the two guards nothing reaches, handoffs/HANDOFF-x86-debug.md added debug information, and handoffs/HANDOFF-x86-cost.md measured what the backend costs and set the survey running on its own so a refusal cannot sit unnoticed again.

The other six sessions are unrelated to each other. handoffs/HANDOFF-arith.md is why a divide by zero is a condition rather than a SIGFPE. handoffs/HANDOFF-raylib-ports.md is the running record of the last two raylib example ports, whose lasting findings were folded into PORTING.md, and handoffs/HANDOFF-cimport-ptr.md is the arm cimport.ml's header check had been promising in a comment and not implementing — which is what those two ports found, worked around and wrote up. handoffs/HANDOFF-devtest-noise.md is the linker error dune test used to print on every run. handoffs/HANDOFF-emacs-flake.md is the test_emacs flake that turned out to be SIGPIPE killing the daemon mid-reply, and it is worth reading for the two mechanisms it rules out as much as for the one it found. handoffs/HANDOFF-tidy.md is this reorganisation.