Compiler Roadmap

[StreamDemon]

Living roadmap for the Sploosh compiler. Phases map directly onto the language specification (docs/spec-plans/LANGUAGE_SPEC.md, currently v0.5.14-draft) — the spec is authoritative and each phase implements the sections listed. GitHub Milestones group the issues for each phase.

Status: Frontend in progress. The lexer + parser + AST bootstrap landed in #57 (crates sploosh-ast, sploosh-lexer, sploosh-parser). The parser currently covers a subset of §16 — see the "Implemented subset" note in crates/AGENTS.md.

Phases

1. Frontend: Lexer & Parser — §2, §16 · milestone 1 · active

Tokenizer and recursive-descent parser producing the AST; goal is full §16 coverage with corpus fixtures and parse→print round-trip validation.

• Parser: match expression parsing (§5.2) #59 — match expression parsing (§5.2)
• Parser: while, for, and loop (§5) #60 — while / for / loop (§5)
• Parser: closures (|x| expr, move) #61 — closures (|x| expr, move)
• Parser: block-like expressions as statements without trailing ; #62 — block-like expressions as statements
• Parser: represent generic parameters in the AST #63 — generic parameters in the AST
• Parser: parse trait and impl bodies into the AST #64 — trait / impl bodies in the AST
• Parser: preserve let mut / &mut mutability and send #65 — preserve let mut / &mut / send
• AST Field drops attributes — #[indexed] lost on onchain event fields #58 — field attributes (#[indexed]), parsing half
• Parser: pretty-printer + parse→print→parse round-trip validation #67 — pretty-printer + parse→print→parse round-trip validation (validates §16 against the spec's own examples)
• Parser: grow the corpus from spec examples (§15, §16) + grammar fuzzing #68 — grow tests/corpus/ from the §15 REST-API and §16 examples; later, grammar-generated fuzzing

2. Name Resolution & Modules — §10 · milestone 2

Module tree, path and use resolution, visibility, orphan rule.

3. Type Checking & Inference — §3 · milestone 3

Types, generics, traits/supertraits, local inference (default i64/f64), dynamic dispatch (§3.5–§3.9).

4. Ownership & Borrow Checking — §4 · milestone 4

Move/copy/borrow, lifetimes, Shared<T>, Box<T>, integer-overflow semantics, no static mutable state.

5. Diagnostics — §18 · milestone 5 · cross-cutting

Stable E/W/L codes, severity, primary spans, suggested fixes, JSON NDJSON (schema: 1). Begins in the frontend by graduating the current flat ParseError into the §18 model.

6. Code Generation & Targets — §11, §13 · milestone 6

LLVM lowering (native/wasm), EVM/SVM backends, compiler intrinsics & math lowering, the on-chain surface. Targets: native/wasm/evm/svm. Includes the EVM topic-validation/codegen half of #58 (#[indexed]).

7. Runtime, Stdlib & Concurrency — §7, §8, §9, §13, §14 · milestone 7

Actor runtime & supervision, iterators, strings/formatting, prelude, files.

8. Tooling — docs/tooling, §13.3 · milestone 8

sploosh build|test|check, manifest (sploosh.toml), package management, editor/LSP.

Working principles

• Spec is authoritative. When compiler behavior and the spec disagree, fix the compiler — or land a spec amendment first (docs/runbooks/compiler-development.md).
• Corpus-driven. Every accepted grammar shape gets a tests/corpus/ fixture; spec examples are the source of truth for fixtures.
• Sequencing. Frontend → name resolution → type checking → borrow checking is the dependency spine. Diagnostics and Tooling grow alongside; Code Generation and Runtime follow a usable middle-end.

Not a compiler phase

• Spec debt Spec follow-ups from the docs drift sweep: FsError, on-chain param refs, dynamic map keys #54 (FsError naming + §6.4 hole, on-chain param-ref rule, dynamic map keys) is tracked separately as a spec amendment, not a compiler milestone.