Concrete is a fully proven systems programming language with no garbage collector, where you can know everything a program does: what it does, what it may touch, whether it can fail or stop, and what is proved about it. Every unproven step is named as an explicit assumption, never silently trusted. This states the project's goal: each guarantee holds only as its evidence lands, compiler correctness and program correctness need separate proofs, and native claims remain conditional on their named assumptions (decision).
It checks resource ownership, makes external authority explicit at every use, and is specified in Lean so that its rules can be proved about. From the first compiler slice, you can ask the compiler what any function may do: its capabilities and reachable resources, allocation, trusted and foreign boundaries, how each possible failure is handled, termination and proof status, each with its reason and evidence (decision).
Accepted safe code has no hidden traps: an index, a division, a shift or an arithmetic operation is either proven safe when the program is compiled or has its failure handled in the code. Before a program runs, every function has termination evidence with its premises, or a report naming the explicitly permitted unresolved obligations, each traced to a written permission at the loop or boundary responsible, and the compiler reports recursion depth, stack use, allocation, blocking and foreign calls per function, SPARK-style. Each guarantee holds as its evidence lands (decision).
Producing an implementation is becoming cheaper. Establishing what it must do, what resources it may use, and why we should trust it remains difficult.
Concrete's direction is to make those obligations explicit: state the behavioral contract, constrain ownership and authority, and attach evidence to the exact implementation being checked. An implementation can change; the obligations it must satisfy remain the basis for acceptance.
That requires more than matching return values. Failure, mutation, external actions and resource behavior can matter too. The scope of each claim and its remaining assumptions must be visible. Understanding the specification and checking that it captures the intended task remain engineering responsibilities.
| Question | Concrete's approach |
|---|---|
| Who owns this resource? | Linear ownership and scoped borrowing. |
| What authority does this operation require? | Capabilities declared in signatures. |
| What behavior must this implementation preserve? | Explicit contracts and semantic obligations. |
| Why should I accept this claim? | Distinct proof, test, runtime-check and assumption evidence. |
The long-term goal is verified compilation from source to native execution, with evidence that can be composed and independently replayed. This is a target, not a current guarantee.
Status: restarting. A new compiler is being built from a Lean specification. Nothing at this root compiles Concrete programs yet.
- Why Concrete exists and the rules it follows: docs/PHILOSOPHY.md.
- The language (normative): ConcreteSpec/. Its README, the reading guide, and
the browsable owner view generated by
scripts/spec/lean_site.shland with the integrated spec (A2i). - The compiler architecture:
Concrete/README.md, which lands with slice 0 (the pipeline decision summarizes it). - Decisions, and what waits for the owner: docs/decisions.md.
- Next work: ROADMAP.md.
- Proposals awaiting the owner: docs/proposals/.
A non-normative tutorial comes in phase C (R-0334).
| Path | What it is |
|---|---|
| ROADMAP.md | The plan, in order. It decides nothing; the decisions below do. |
| docs/PHILOSOPHY.md | What Concrete is for and the rules it follows. |
| docs/decisions.md | The owner's recorded language decisions. |
| docs/proposals/ | Proposals and reviews awaiting the owner's decision. |
| ConcreteSpec/ | The specification: readable Lean with doc comments and examples. |
| AGENTS.md | How work is done and landed here (humans and agents alike). |
| ISSUES.tsv | Defects in the spec, proofs, CI and tooling, until the new bug ledger returns. |
| RETENTION.tsv | Where every asset of the old tree went, and when it may be deleted. |
| legacy/ | The old compiler and everything around it, frozen byte for byte. |
| Part of Concrete | Main precedent |
|---|---|
| Linear ownership, scoped borrows, capabilities in signatures | Austral |
| Mutable value semantics: mutation through scoped access, no returned or stored references | Hylo (formerly Val) |
| A small explicit language: no hidden control flow or allocation, allocators passed as parameters | Zig |
| Compiler-enforced safety culture and an explicit trusted boundary | Rust |
| Verified compilation: source behaviour carried down to the binary | CakeML and CompCert |
| Absence of run-time errors and the assurance workflow | SPARK, with Dafny and Why3 |
| Rules and proofs in one checked system; the implementation language | Lean 4 |
Smaller influences include Aeneas and Effekt. The full comparison, including what Concrete takes from each and what it rejects, is archived in legacy/docs/project/INFLUENCES.md.
legacy/ is a frozen snapshot of the old tree: it is never edited and never run here. The old
compiler is tag legacy-compiler-final; to use it, check that tag out in its own worktree. The
differential oracle is built from the tag, not from legacy/ (scripts/oracle/). Assets the new
compiler still needs (programs, examples, std, the bug ledger, the site) stay archived in legacy/
until they migrate; RETENTION.tsv records each one.
nix develop # Lean and the tools the checks use
lake build # the specification
bash scripts/checks/run.sh # the root checks (also run by the pre-push hook and CI)