seed Language — Product Requirements
This page records the active product requirements for seed. It is not a second
grammar or implementation-status page. Normative language behavior lives in
seed/docs/lang-spec.md; implemented claims and target levels live in
Current Status.
Product objective
seed is a statically typed systems language for native programs that need:
- deterministic memory and resource behavior without a garbage collector;
- safety checks that remain enabled in optimized builds;
- a smaller ownership model and language surface than Rust or C++;
- fast parsing, checking, compilation, and incremental reuse;
- explicit low-level access when safe abstractions are insufficient;
- structured concurrency without language-level async/await.
The primary product wedge is controlled systems software: CLI tools, internal services, binary/text processing, native libraries, and freestanding work at the target levels explicitly closed by compiler gates.
Non-goals
seed does not require or promise:
- garbage collection, exception unwinding, lifetime syntax, macros, classes, inheritance, virtual dispatch, or language-level async/await;
- compatibility with legacy seed syntax or superseded compiler backends;
- an unchecked optimization profile that silently weakens safe semantics;
- universal performance superiority over C, Rust, Zig, Go, or managed runtimes;
- hosted support on a target merely because LLVM object emission exists;
- self-hosting before the operational LLVM compiler and ecosystem are stable.
Language requirements
| Requirement | Current acceptance criterion | Evidence |
|---|---|---|
| Static types with inference | Every accepted program is typed before MIR; public interfaces preserve types | language specification and .sdi tests |
| Predictable ownership | Scalars copy; resources move; clone is explicit; live owners clean exactly once on structured exits | Gates 10–11 and ownership tests |
| Safe borrowing without lifetime syntax | Views carry lexical/input/receiver provenance and cannot outlive backing storage | ownership/provenance tests and schema interfaces |
| Explicit allocation failure | Safe allocating APIs return result<..., alloc_error> or another declared error |
option/result and library tests |
| Checked data access | Safe indexing, slicing, discriminants, and mutable partitions validate their contracts | Gates 6, 16, and 19 |
| Explicit unsafe boundary | Raw memory, pointers, FFI, syscalls, unions, atomics, volatile access, address spaces, and assembly require unsafe |
safety contract and negative tests |
| Deterministic release semantics | --release and --release-small preserve safe checks unless LLVM proves them redundant |
Gate 13 profile tests |
| Structured concurrency | Spawned work drains at lexical boundaries; transfer and sharing require capabilities | Gate 6 task/runtime tests |
| Recoverable ordinary failure | Options, results, postfix ?, and typed task results preserve ownership and cleanup |
Gate 6 and Gate 15 tests |
| UTF-8 source and text | Source and owned text reject malformed UTF-8; byte length and Unicode-library boundaries stay explicit | loader and text tests |
Memory model
The required common model is:
- Copy-capable values copy.
- Owned resources move on assignment, calls, returns, captures, and aggregate construction.
- Borrowed
str,[]t, andmut []tviews retain provenance. .clone()is explicit and its allocation/retain effects are part of the public contract.- Cleanup runs once in reverse successful-initialization order on structured exits.
linear tadds an exactly-once obligation without changing representation.- Regions provide checked lexical bump allocation and reject escaping safe owners, views, and pointers.
- Panic, trap, and abort do not unwind or run lexical destructors.
The current operational details are documented in Ownership.
Compiler requirements
The operational compiler is seed/compiler/llvm. Its required pipeline is:
source → lexer/parser → semantic graph → typed HIR/CFG
→ ownership/provenance/effects/loans → cleanup planning/verification
→ MIR → target layout/ABI → verified low MIR → LLVM
The Linux x86-64 self-hosted replacement is an active gated migration under
roadmap-self-hosted.md. Until its SH20
cutover, seed/compiler/llvm remains the operational compiler and semantic
oracle. Other self-hosted platform ports are deferred until after the first
Linux x86-64 cutover.
Every source and source-elided interface path must pass the same relevant typing, ownership, provenance, effects, cleanup, ABI, and profile checks before code generation.
The compiler must provide:
- human and JSON diagnostics with stable source locations;
- formatting and semantic/IR inspection modes;
- LLVM IR, object, executable, shared-library, and static-library emission at each target's declared level;
- safe release profiles and explicit independent ThinLTO/PGO/static-linking choices;
- separate compilation through validated
.sdiinterfaces; - exact target, ABI, build-profile, runtime-profile, dependency, and inline-body identity for reusable artifacts;
- deterministic rejection of malformed, stale, incompatible, or corrupt interfaces and cache entries.
Superseded OCaml, QBE, TCC-style, and assembly-stub compilers are compatibility history only and do not satisfy current product requirements.
Runtime and target requirements
Target support must be described as a capability matrix, not a boolean. Parse, LLVM, object, archive, shared library, executable, hosted run, runtime services, FFI, scheduler, package artifacts, and boot evidence are tracked separately.
The canonical matrix is
seed/compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv. Linux x86-64 is the primary
closed hosted target. Gate 14 is complete after required native macOS x86-64
evidence; macOS arm64 has its separately verified native host row and does not
substitute for the Intel closure requirement. WebAssembly/WASI is currently
object-only.
Freestanding and kernel profiles must declare their available runtime services. Allocation, blocking, panic, I/O, networking, and scheduling effects may only be used when the selected profile provides them.
Library requirements
The language core remains small. Files, networking, parsing, formatting, collections, tasks, and system wrappers are ordinary libraries with explicit interfaces rather than hidden built-ins.
The operational repository set is under seed/compiler/llvm/libs and is
documented in Library Reference. Libraries must:
- expose ownership, provenance, mutation, allocation, panic, blocking, and unsafe effects in their signatures/interfaces;
- prefer safe wrappers over raw runtime or FFI operations;
- return typed errors for recoverable failure;
- preserve exact cleanup for partially initialized and moved values;
- avoid presenting legacy Grove APIs as current compiler built-ins.
The larger top-level grove/ tree is a compatibility and porting corpus until
an individual package passes the operational compiler and receives a current
manifest/interface contract.
Tooling requirements
The repository launcher and direct compiler together must support:
- check, build, run, and test workflows;
- reproducible dependency resolution, lockfiles, and caches;
- incremental object/interface reuse with exact invalidation;
- package validation and platform declarations for FFI packages;
- LSP diagnostics, formatting, linting, and generated documentation;
- transactional user/system install and reference-aware uninstall;
- static and dynamic library consumption without source-dependent semantic shortcuts.
The executable seed --help remains authoritative for direct compiler
flags. Language Reference documents the repository launcher.
Performance and quality requirements
Performance claims require controlled evidence. Current closure gates enforce:
- a 100k-line full-check scalability budget;
- equivalent C/Rust comparison corpora for runtime, startup, RSS, artifact size, parsing, allocation, collections, networking, and tasks;
- safe-profile behavior rather than unchecked benchmark-only semantics;
- normal and ASan/UBSan validation of compiler/runtime unit binaries;
- benchmark methodology that distinguishes workload time from suite-level compile time, RSS, LOC, and artifact size.
The current cross-language snapshot is in Benchmarks. It is a local measured corpus, not a language-wide ranking.
Current product gaps
The main remaining product gaps are:
- Gate 14 native macOS x86-64 closure and broader hosted portability evidence;
- porting or replacing legacy Grove packages with clean-language packages;
- ecosystem breadth and stable third-party distribution;
- IDE, debugger, formatter, and operational tooling polish;
- optimizer and application evidence beyond controlled compiler gates;
- production history and compatibility guarantees across releases.
New requirements should be added here only when they describe product intent.
Grammar belongs in the language specification, implementation status in
status.md, and planned compiler work in seed/compiler/llvm/ROADMAP.md.