Submit and commit
Submissions, scripts, and keeping calls enter through a transaction. Deliberate changes become numbered acts.
submit · run_script · run_callableTHE RUNNING APPLICATION
A runtime for software that stays live.
Programs live, compile, and act where the product is running. A scene, selection, tools, and live values can keep moving while people and agents change the code around them. It is also the sandbox: the agent lives inside the runtime, and everything it does — every read, every write, every experiment — happens within it, under its rules.
One environment holds both speeds of the application. The committed tier: saved values and their history. The live tier: the same names moving at interaction rate — a selection, a pose, a tool's current state. A live read is a snapshot that cannot tear.
Live movement creates no history on its own. Keeping a value is deliberate: a recording run commits, and the change lands as one numbered act the team can inspect.
Showing the last kept value
No recorded act
Showing committed value 24. 0 recorded acts.
02 / ATOMIC PUBLICATION
The compiler checks types, calls, and finite authored computation before execution. A recording run works in its own staging: it sees its pending writes while everyone else still sees the standing state.
At commit, completed declarations, bindings, and staged application state publish together as one act. If execution or preparation fails, the current uncommitted stage is discarded. Nobody sees half of that publication.
Pending writes belong to this evaluation.
Every participant is ready before anything lands.
Readers see the completed change together.
Atomicity is per commit. A program can commit intermediate results; those earlier acts stand if later work fails. Native effects performed outside the transaction, such as writing a file or printing a line, are not rolled back. Diagnostics raised during cleanup name the act that committed.
03 / THE WALK
Every recording act archives its deed. The log has numbered positions; value history is a projection of those acts. Undo and redo walk the retained record by appending restoring acts, so the order never rewrites itself.
The archive alone can reproduce a workspace in a fresh process, given the same host capabilities and inputs. Replay executes recorded deeds again; performed external effects can run again, while unrecorded live gestures and outside reads are not reconstructed from the archive.
The host remains responsible for native providers and external effects. Value retention bounds what undo can restore; source replay is the deeper road for older state.
watch.attach(..live to: T, body: (..T | missing) -> none) -> watch.idThe live parameter accepts one tracked name or a product of names.
watch.attach observes one live entry or a product of them. The body receives their newest values, or missing. Its captured values are frozen when attached; reads inside the body are fresh and do not add tracked inputs.
Without every:, a tracked change makes the body due. With it, the host delivers elapsed virtual time on a cadence. Under load, missed intervals coalesce into one delivery with an elapsed jump: time is the contract, not a count of ticks.
Median wake after a foreign write. Apple M4 Max, Release; medians of five gate runs.
Entering a mode opens a scope. The scope journals every live entry its bodies touch, at first touch. At every ending, those entries return to their previous values, or disappear if the mode created them. No one writes cleanup code for the working set.
A tool is one example — a mode offered in the interface. Steering the camera or opening a temporary workspace is a mode in the same way. A person's own drag or form write belongs to no mode scope and survives. Key bindings, including Escape, are authored entries; the framework does not hide a second behavior path.
Restoring these entries releases the scope's ownership of its temporary values. Storage ends when the last owner releases it; history, snapshots, or captures can deliberately keep it alive. Restoring state and releasing memory follow distinct rules, without a cleanup routine written for every mode.
How deterministic ownership worksThe mode begins with the current live environment.
The scope journals only the names its bodies touch.
Exit, replacement, close, or fault restores the scoped working state.
06 / TWO ENTRY DOORS
The entry door decides whether an evaluation records. A submission, script, or keeping call runs the completion transaction. A live call evaluates a retained body without that transaction, so its admitted writes perform where they stand and create no record. People and agents share these runtime rules.
Submissions, scripts, and keeping calls enter through a transaction. Deliberate changes become numbered acts.
submit · run_script · run_callableWatches, mode bodies, and live interactions call retained programs. Their writes stand without a receipt.
runtime::callA read of the world is an observation, not a write. Read-only bodies may run on workers when their native calls are reentrant; world writes remain on the ordered lane. Native providers keep responsibility for their declared behavior.
07 / WAITING WITHOUT HOLDING THE TURN
A host that chooses yielding suspends the program at an unsettled await and takes its turn back. Its values and place in the compiled program remain retained. When the future settles, a readiness notification schedules a turn to resume that same invocation.
The host chooses the waiting policy: yield, permit blocking, or refuse a wait that would block. A future that is already settled proceeds immediately. Spawning work returns a future; the host's dispatcher decides where that work runs.
The host owns the loop. It calls step(now) on its chosen thread and receives the next deadline, or none. A wake notification asks for another turn. Live bodies and world writes run on that stepping thread; admitted workers compute values those bodies use.
Luna proves its own computation finite. A future still depends on an answer arriving, and a foreign function must return before its caller can continue.
The compiler is part of the runtime: programs are compiled, checked, and retained in the same process that runs them. An embedded console needs the compiler, runtime, shared terminal, and the modules your application installs. It needs no window or presentation modules. People and agents submit to the same session; the application can call the functions they publish.
Native domains add their own types and operations through typed contracts, including layout and lifecycle laws. Installation or replacement publishes a complete generation or nothing. Retained compiled programs pin the exact generation they were checked against, so replacing an implementation cannot silently redirect old code.
The agent can inspect authored Luna source, signatures, and documentation to learn and extend existing behavior. Native implementations remain private behind their exposed contracts. Adding the application host brings scene, tools, panels, and live interactions over that same runtime; desktop and WebAssembly share the language core.
See the two adoption pathsExpose selected types, operations, and their contracts.
Inspect source. Author a function. Publish it for the application to call.
Build the interface over the same language and environment.
LUNA
A language for new capabilities, and a runtime for the live application that holds them.