Where loom is going

Every other page on this site describes the binary as it is built today. This one does not. It is about where loom came from and what it is likely to become, and where it talks about something unbuilt it says ahead and means it. Nothing here is a promise, a schedule, or a feature you can use.

What LuciaOS wanted first

Before there was a language, there was an architecture. It is still in the repository, in docs/v1/, and it opens like this:

A persistent computer made of connected things.

Loom does not begin by making the computer intelligent. It begins by making the computer coherent.

The argument was that files, folders and applications are useful forms but poor ground truth. A file binds information to one container; a folder gives it one official location; an application decides where information, capability and interface end. Moving work between them means copying, importing, exporting, or asking one program to understand another.

Underneath all of it, v1 put a persistent Fabric: identity-bearing Texels connected by typed Fibers, with a small enough vocabulary to hold in your head — LuciaOS, Loom, Fabric, Texel, Port, Fiber, View. Seven words. Evaluation was demand-driven and cached: push invalidates, pull evaluates, and nothing recomputed merely because it existed. Effects were data — a Texel computes an intent, the engine checks a connected capability, a trusted boundary performs it, and the result comes back as an observation. Interfaces were Views: ordinary Texels whose computation produces a screen, so the same material could be prose or a table or a map without being imported into three applications. Capability arrived through explicit connections, never ambiently.

The slogan that carried it was connecting is filing: to put something somewhere is to connect it into a context, and organisation accumulates without one context erasing another.

And in v1, "Loom" was that engine. Not a terminal — the trusted local engine at the center of the system, which stored, connected, evaluated, scheduled and protected the Fabric. It was built. It worked. There was a terminal in front of it with commands like set, eval, pull and watch, and a plan for where that terminal went next.

What v2 did about it, and why

v1 taught the project one thing that outranked everything else it taught, and the north star document states it plainly:

It worked, and it taught us the most important lesson of the project: Luce is the part that enables everything else. Every other layer — storage images, texels, fibers, access rights — made iteration slower while the language was still growing.

So v2 restarted from the first principle instead of from the architecture. The whole persistent substrate was set down — deliberately, with the tree preserved on a branch and the documents kept where anyone can read them — and the effort went into the language.

What was set down is not vague. It is a list: the Fabric, Texels, Fibers, Ports, Views, capabilities-as-values, the Spool, the persistence image, Braids and network synchronisation, multi-user anything, and the agent. The v1 fabric builtins and their compile-time gate were removed from the compiler entirely rather than left switched off.

What was kept is a shorter list, and more interesting:

• The discipline that computation receives no ambient access. v1 said capability arrives through explicit connections. v2 says every effect is a service the host hands over, and one it does not hand over refuses rather than guesses. Different mechanism, same principle, and the one that survived contact with a real compiler.
• Effects as a boundary rather than as ambient power. v1 had trusted boundary Texels performing effect intents. v2 has a versioned table of function pointers that generated code indexes, where every service is optional and fail-closed.
• Familiar computing at the edge. v1 already said files remain useful as portable byte artifacts and that the way to use an existing tool is to project a region into the environment that tool expects. v2 took that all the way down: ordinary OS files are the storage, and there is no image to initialise.
• A small vocabulary held on purpose. v1's rule was "the machinery may grow; the ontology should not." v2's version is a language with no classes, no inheritance, no first-class functions, one engine, and one implementation of every semantic.

The name is the only claim being made

v1's Loom was an engine. v2's loom is a terminal that opens a shared library and calls it. That is a very large demotion, and it was not an accident of naming.

Today loom is the smallest thing that honestly deserves the name: it is where a program becomes a running thing, and it is the trusted boundary between a program and the machine. Those are the two jobs v1's Loom had that did not depend on the Fabric existing. Everything else it did — storing, connecting, scheduling, evaluating — is not there, and this site does not pretend otherwise.

The north star's roadmap ends with one line about the rest:

Then — and only then — persistence and the return of the Fabric.

What is planned, and written down

These are recorded in the repository as work to do, not inferred:

• aheadGrowing the terminal. Mouse, bracketed paste, and incremental drawing — damage tracking inside the host, with the same builtins. A program keeps saying "draw this here"; the host stops repainting what did not change.
• aheadMore userland. A formatter, a grep, a file browser. Written in Luce, run by loom, in the repository beside the editor — which is the pattern: things loom does are programs, not commands built into loom.
• aheadCross-compilation, and sharing one runtime library between artifacts instead of copying it into each. This is the compiler's work rather than loom's, but it changes what loom's install tree looks like and how big a .lc is.

None of that changes the shape of the tool. It is loom getting better at what it already does.

Where the growth actually is

aheadEverything in this section is a reading of where the project's own decisions point, not a plan anyone has committed to.

The interesting question is not whether the Fabric ideas come back — the north star says they do — but where they come back. There are two doors, and the project has already chosen one of them for everything else.

Not through the language

Luce's memory story is scope ownership: no garbage collector, no reference counting, no hidden runtime bookkeeping, and a compiler that can tell you at compile time who owns what. Persistent identity — a thing that outlives the scope that made it, is reachable from several places at once, and is still there tomorrow — is exactly the shape of problem that ordinarily drags a runtime collector in behind it.

That trade has been refused, and the refusal is written down — docs/MEMORY.md is the record of why scope ownership won and what it beat. So durable identity does not arrive as a new kind of Luce value. Whatever it becomes, it is not Texel as a type in the language.

Through the tool

The other door is the one loom already is. The host boundary is a versioned table of services, and it is append-only. A new capability — durable storage, content addressing, a way to demand a value and be told when it went stale — is a new row in that table and a new builtin that calls it. The language does not change to gain it. The compiler does not learn a new semantic. An artifact built against the older table is refused by name rather than handed a table it does not understand, so the growth is safe by construction.

That is not a hypothesis about the future; it is how every effect loom already offers got there. Files, the terminal, the clock, the machine facts, and the program's own exit status are all rows in that table, added over time, each one bumping a version.

Read that way, the v1 vocabulary has plausible v2 spellings, and each one is a service rather than a language feature:

The point of that table is not that the mapping is obvious or that the work is small. It is that every row of it is loom's work rather than Luce's — which is what "loom will grow a lot" means when the language is deliberately staying small.

The seed that is already there

loom already keeps exactly one thing between runs, and its properties are the ones a persistent substrate would need: the artifact cache is content-addressed (its name is a hash of the program, so nobody has to invent a naming scheme), self-validating (an entry that does not match is refused by name rather than used), disposable (deleting it costs a recompile and never correctness), and unmanaged (there is no sweep, no lock, no age policy, and no daemon). Four properties, and they are the same four v1 demanded of its caches.

It is a cache of one kind of thing, not a Fabric. But it is the shape, running in production, in a tool that carries no engine.

What will not happen

Being clear about the direction is worth less than being clear about the walls.

• loom will not become an engine again in v1's sense. There is no interpreter inside it and no plan to put one there. A .lc is machine code; the interpreter that exists is a test-suite oracle and ships in nothing.
• Luce will not gain a garbage collector or reference counting. That includes hidden runtime refcounting introduced to make some other feature convenient. It is a standing rule, not an open question.
• The shell will not accumulate state. No variables, no history, no configuration, no cd. Things loom does are programs.
• Nothing will be added to the boundary quietly. Every effect is a row in a published table, and every change to it bumps a version that artifacts carry. That is the mechanism that makes growth safe, and it only works if it is never worked around.

Reading further

All of this is in the repository, which is where to go when this page and the code disagree — the code wins, and this page is what needs fixing.

• docs/v1/LOOM.md — the original architecture, entire and unedited.
• docs/v1/PLAN.md and docs/v1/EVALUATION.md — where the v1 terminal and its evaluation engine were going.
• docs/V2.md — the north star: what v2 is for, what it deferred, and the roadmap that ends with the Fabric.
• docs/ENGINE.md — why there is one engine and what the oracle is for.
• docs/MEMORY.md and docs/OWNERSHIP.md — the memory decision this page leans on, and the rules it produced.
• luce.luciaos.com — the language, and its own honest page about what it cannot yet do.