Joseph Ferano
f182fb4728
Item 3, and the reason the backend was written. Until now --x86 was read only by flan build's argument list; the daemon built both halves through LLVM, so none of this reached the dev loop at all. The choice is a session setting, not a per-command flag, and it is spelled exactly as [debug] already is -- one field on Session.t, set once in Dev.start, carried on every change the session emits. session.ml's comment on [debug] already gives the reason and it is the same one: the modules have to match the process they are loaded into. Session.redefinition is the single place that picks a backend, so the six call sites cannot disagree and the refusal has one home. Session.change carries the answer beside the text, so the builder and the text can never come from two different decisions. There is no fallback and there must not be one. X86.redefinition refusing a form is reported to the editor; quietly building an LLVM module instead is precisely the crossed pair flan.abi.x86 exists to refuse at dlopen. A refusal reaches the editor as a diagnostic like any other -- X86.Unsupported is re-raised as a Loc.Error at the form it is about, because every caller already handles that and none handled the other, and a session that died on the first unsupported form would be worse than one that says so and stays up. flan reload got the same flag at the same time. A command that could build a module for a host the other backend compiled is how the crossed pair was reachable from the CLI at all; the aggregate handoff's two-line reproduction no longer has a second half. And the finding: flan dev --x86 refuses the merged daemon. A merged build is the program and the compiler in one process, and the compiler expands macros by dlopening a module Build.macro_module made through Emit.program, cached on disk by the macro source rather than by the backend. The merged host is linked -rdynamic so a redefinition module can reach its cells, which also exports every flan.* body it has -- so the macro module's own copy of a prelude function is interposed by the host's. With an LLVM host nobody notices. With an --x86 host the caller is LLVM and the body it lands in is this backend's, and the process dies inside flan.[clamp] during the first macro expansion, before the program has started. flan.abi.x86 does not catch it and was never meant to: a macro module deliberately neither defines nor requires a marker. The honest fix is hidden visibility on a macro module's Flan bodies, which changes the cached object for both backends and wants a lane of its own. Until then the refusal names the mechanism and the remedy, and --two-process has no such meeting. start_merged keeps its --x86 plumbing, unreachable for now, because it is the half that is right and will be wanted the day the macro module is fixed. test_dev.ml drives an --x86 daemon through C-c C-c, C-x C-e, a literal, a new defvar with a value of its own and a new defn, and asserts (twice fresh) is 82 -- which only holds if both registry lookups resolved. The merged refusal is asserted there too. bin/main.ml learned to print a bare Failure as a sentence rather than an uncaught exception and its backtrace.
Flan
A statically typed Lisp for native games and interactive development.
Flan is an experimental, ahead-of-time compiled Lisp for programs that need predictable memory use and a fast edit–run loop. It combines S-expressions, static types, explicit ownership, and a development session that can replace a function in a running program without resetting its state.
It is being built around games, but the interesting part is broader: a compiled language where the running program remains available for inspection, experimentation, and small changes.
In practical terms: you get parentheses, a debugger that would like to have a conversation, and no garbage collector quietly choosing the dramatic moment to join your frame loop.
What it has
- Native compilation through LLVM, plus an in-progress direct x86-64 backend.
- C-like data layout: structs, fixed arrays, pointers, slices, and explicit allocation. There is no garbage collector.
- Owned
VecandMapcontainers, plus checked moves and borrowing-oriented slice operations. - Generics, algebraic unions, enums, macros, packages,
defer, and a C FFI. - Conditions and restarts for recoverable failures and interactive debugging.
- A raylib package and a collection of ported raylib examples.
- Native, WASI, and web build targets. The cross targets are useful but less complete than the native development workflow.
The project is exploratory software, not a stable language release. Some features are deliberately refused while their semantics are still undecided; the compiler aims to say why rather than quietly accepting a partial version. It has opinions, but at least they arrive as error messages.
Quick start
Building requires a current OCaml/Dune toolchain, LLVM/Clang, and the native C toolchain. Raylib is only needed for programs that use the bundled graphics package.
dune build
dune exec ./bin/main.exe -- run web/examples/hello.flan
To build a standalone native executable:
dune exec ./bin/main.exe -- build web/examples/hello.flan -o hello
./hello
The falling-sand demo uses raylib:
dune exec ./bin/main.exe -- run sand.flan
Once you are iterating regularly, put the built executable on your PATH if
you want to use the shorter flan commands shown below.
The live development loop
Start a long-lived development session:
flan dev sand.flan
The program runs normally and publishes a local socket beside the source file. The bundled Emacs mode can attach to it, evaluate expressions in the live process, inspect a stopped program, and recompile a top-level function from the buffer. A body change takes effect on the next call; changing a function's signature is intentionally rejected. The program keeps its state, which is especially nice when you have finally arranged the sand into something almost worth saving.
To set up the mode:
(add-to-list 'load-path "~/path/to/flan/emacs")
(require 'flan-mode)
Then use M-x flan-dev to start and attach, or C-c C-z to attach to a
session started in a terminal. The editor workflow is documented in
emacs/MANUAL.md.
A small example
(defstruct AssetMissing [id i32])
(defn load-asset [id i32] i32
(signal (AssetMissing {.id id}))
100)
(defn asset-or-placeholder [id i32] i32
(restart-case (load-asset id)
(use-placeholder [] -1)))
(defn main [] ()
(handler-bind [(AssetMissing [_] (invoke-restart 'use-placeholder))]
(println (asset-or-placeholder 7))))
Here a missing asset signals a typed condition. The handler chooses a restart, so execution continues with a placeholder instead of requiring error values to be threaded through every caller. See web/examples/restart.flan for a runnable version.
Commands
flan check <file.flan> type-check a program
flan run <file.flan> [args...] build and run it
flan build <file.flan> [-o out] [options] build a native executable
flan dev <file.flan> [-s socket] start a live development session
Useful build options include --debug, --sanitize, --no-bounds-checks,
--x86, and --target=wasm32-wasi|web. run is native-only; cross-built
output should be run with an appropriate WASI runtime or browser. A .wasm
file is not a tiny native executable in a trench coat.
Project map
- web/index.html — language reference and fuller examples.
- spec-memory.md — ownership, containers, and generics.
- spec-conditions.md — conditions, handlers, and restarts.
- emacs/MANUAL.md — the interactive editor workflow.
- docs/BUILT.md — implementation rationale.
- NEXT.md — current work and known limits.
License
Flan is released under the MIT License. Third-party material under
vendor/ is distributed under its own licenses.