What is Luce and what is Zig
This map shows where each part of the system is implemented. It answers which repository directory owns a behavior and which boundary connects it to the next layer.
Filter the implementation map
What is written in Luce
The standard algorithms for strings, paths, JSON, ZIP/DEFLATE, HTTP, IO loops, list sorting, and much of math are language source. So are the termui package, the terminal editor, the LSP server, and bundled applications. Hosted public APIs remain Luce declarations even when their final primitive crosses to Zig.
The compiler and runtime remain Zig. Standard algorithms, packages, and applications exercise Luce as userland and can evolve through ordinary language source.
Why the compiler and runtime are Zig
The compiler needs byte-level parsers, arenas, LLVM construction, native object handling, and diagnostic infrastructure. The runtime needs precise C layout, allocators, atomic/thread integration, host callbacks, and platform resource destruction. The apps need filesystem loading, process launch, dynamic loading, and terminal/window adapters.
What belongs to native tooling
LLVM performs target-independent and target-specific optimization, selects machine instructions, assigns physical registers, and emits an object. cc supplies platform startup objects, SDK paths, libraries, and the final link. The OS loader maps the executable or .lc, applies relocations, and exposes the entry symbol.
The placement test
| If the behavior... | It belongs... |
|---|---|
| can be expressed portably with current language semantics | in Luce source |
| defines heap identity, lifetime, representation, or traps | once in the Zig runtime |
| decides source meaning or emits protocol | in the owning Zig compiler stage |
| touches platform state | behind the host table in an app adapter |
| is general machine optimization | in LLVM, informed by accurate alias, effect, and lifetime metadata |