The decisions that shape Luce

Why do integers trap instead of wrap? Why do workers copy instead of share? Why are structs and classes separate? These are not isolated preferences; each one simplifies several later parts of the compiler and runtime.

Load-bearing principles

Make representation changes visibleTypes name widths; conversions, identity, failure, host effects, and worker boundaries are explicit. Implement each semantic onceNative code and the oracle share one runtime rather than maintaining parallel object models. Give each stage authorityParsing owns syntax, semantics owns source rules, lowering is mechanical, verification owns protocol. Refuse stale native codeVersion and identity checks rebuild or reject; no compatibility shim executes ambiguous bytes. Compare behavior broadlyOutput, errors, traps, traces, host world, and live objects all count as language behavior. Pay the complete change costA feature updates every affected representation, specification, public page, and version together.

The architecture in four arrows

apps → luce moduleproducts consume the language through its public compiler/runtime surface

specs → both pathsprogram behavior is never proved on only one execution implementation

both paths → runtimeARC and dynamic semantics have one body

artifact → host tablenative code touches the world only through an explicit versioned capability interface

Before 1.0, remove old designs cleanly

Luce does not promise source compatibility before 1.0. A better spelling or model changes the tree coherently; deleted names do not remain as deprecated aliases. Serialized MIR and native ABI versions exist to reject stale artifacts safely, not to translate them.

Compatibility and correctness are different jobs. A stale cache can recompile. Preserving two meanings for one pre-release feature would make every later stage and document carry permanent branching complexity.

Mechanisms deliberately absent

No VM fallback, duplicated runtime, implicit numeric promotion, class inheritance, shared worker heap, manual memory API, tracing collector, mutable global state, reflection, or macros currently sits behind the surface. A future feature must earn its mechanism with a real customer and a complete acceptance matrix.

Current truth, plans, and history

Current references describe code that exists. Plans use non-compilable text for syntax not implemented yet. Decision records preserve only boundaries whose history remains useful. Keeping these categories separate prevents an intended feature from being mistaken for a language promise.

repository architecture design discipline document categories product north star