Roadmap

The AbySS interpreter already ships collections, artifact structs and methods, themed pattern matching, a browser playground, and VS Code tooling. The sections below outline what is delivered today, the next few release cycles in priority order, and the longer-horizon items still in design — including the staged path towards self-hosting.

Guiding priorities

The ordering below follows four rules:

1. Ship merged value first — work sitting on develop is released before new work starts.
2. Everyday gaps before new machinery — string helpers matter more than editor tooling while both are missing.
3. Error handling before anything that can fail — file I/O and fallible stdlib APIs are designed after fate / augury exist, so nothing has to be retrofitted.
4. Deep semantic changes last — modules, enums, and generics land once the infrastructure they lean on is stable.

Vocabulary principles

AbySS’s reserved words are the language’s signature. New keywords are chosen by four tests, induced from the existing vocabulary (forge, ward, orbit, scribe, …):

1. The metaphor explains the behaviour (orbit = loop, ward = guard).
2. Five-to-seven characters, comfortable to type.
3. Real English words without programming-language baggage.
4. One concept, one word — no collisions or near-collisions (this is why the Option type is not called echo: shell users read echo as “print”).
5. Theming is for keywords, types, and concept-defining APIs (forge, fate, scribe). Everyday utility helpers keep their familiar names (min, max, sqrt, upper) — discoverability beats flavour where no metaphor adds meaning. This is a deliberate split, decided with the v0.6.x stdlib names.

Delivered

• Collection Types – scroll, lexicon, and materia literals plus standard rituals.
• Artifact Structs & Methods – Typed schemas, literals, field mutation rules, and TypeName::method syntax with core / morph core receivers.
• Themed Pattern Matching (v0.5.0) – oracle if-else and match modes, ward guard clauses, and scroll / artifact / lexicon destructuring.
• Web Playground & Wasm (v0.6.0 cycle) – crates/abyss-wasm adapter and a browser editor on this site, seeded with the examples/ programs.
• Span-tracking & AST Overhaul (v0.6.0 cycle, pulled forward from v0.8.0) – AST nodes and EvalError carry start..end byte spans (runtime diagnostics underline the full offending range), the AST is split into Expr / Stmt / Pattern, and EvalError gained structured variants. Pure infrastructure, no language change — it cleared the runway for the LSP.
• Comment-preserving Formatter (v0.6.0 cycle) – abyss align re-emits comments beside the statements they accompanied, powered by the new spans.
• Vocabulary Fixes (v0.6.0 cycle) – the two off-theme names were hard-switched while the user base is small: the materia conversion method trans → transmute (#524) and the loop-continue keyword resume → revolve (#525). A deprecation/warning channel arrives later with the LSP’s diagnostics model.
• Multi-crate Workspace, Release Pipeline, Diagnostic Polish – as before: independent crates on crates.io, one-push releases with per-target binaries and the VS Code extension, and “did you mean?” hints throughout.

Release Plan

Versioning follows the project’s 0.x.y convention (a 0.x.0 bump signals a potentially-breaking release; 0.x.y is compatibility-preserving).

v0.6.0 — Web Playground & Internal Overhaul (next release — everything is merged)

The release that ships the current develop: the browser playground plus the span/AST/formatter overhaul described above. All breaking API changes of this era (LineInfo removal, the Expr / Stmt / Pattern split, the semantic module removal) are concentrated in this single 0.x.0.

v0.6.x — Standard Library Essentials

Round out the everyday helpers as compatibility-preserving point releases. rune comes first — it currently has no methods, which is the biggest daily-use gap for a scripting language.

• rune methods: upper, lower, contains, split, replace, trim, tally.
• scroll methods: sort, unique, sum, min, max. Empty-scroll min / max raise an error for now; they move to augury returns in the v0.7.x API revision.
• Math rituals that are sandbox-safe everywhere: abs, sqrt, floor, ceil. Time rituals wait for the I/O design.

v0.7.0 — First-class Error Handling (shipped)

Promote runtime failures from “interpreter prints a diagnostic and aborts” to a value scripts can handle. The artifact pattern type-dispatch shipped in v0.5.0 already supports the mechanics; this cycle standardises the types and adds the propagation operator. The Expr / Stmt split makes ? a straightforward postfix expression.

• Stdlib fate type (the themed Result): bless { value } / curse { reason }, ergonomic to construct and to destructure with the existing artifact patterns.
• Stdlib augury type (the themed Option): manifest { value } / naught {} — an augury may reveal something, or nothing.
• New ? propagation operator that early-returns the curse / naught variant from the enclosing function: forge x: arcana = parse(input)?;.
• engrave return-type support for fate and augury, with call-time enforcement.
• Fallible stdlib revision folded in from v0.7.x (a return-type change is breaking, so it belongs in the 0.x.0): scroll.min() / max() return augury, sqrt returns fate.
• try / recover block syntax stays deferred — ? covers the bulk of the use cases.

v0.7.x — Scripting Ergonomics

The quality-of-life layer that makes AbySS practical for real command-line scripts, as point releases.

• invocation — a built-in scroll of script arguments (abyss invoke script.aby -- …); exit-code conventions for curse-terminated scripts.
• aura — a built-in lexicon of environment variables (read-only to start).
• incant — string interpolation as a prefixed rune literal (incant "count: {n}"), additive so existing literals are untouched.
• perish(code) — explicit abnormal termination.
• REPL improvements: multi-line editing and history search.

v0.8.x — LSP MVP

The prerequisites (byte spans, the Expr / Stmt / Pattern AST) shipped early in the v0.6.0 cycle, so this can start any time after v0.7.0. Ship in stages so the VS Code extension layers source-aware features onto its TextMate grammar without waiting for a full implementation. The old SymbolTable scaffold was removed in that same cycle; the server builds a fresh span-aware resolver on the new AST.

1. v0.8.0 – crates/abyss-lsp with the tower-lsp plumbing, exposing parser diagnostics over LSP.
2. v0.8.1 – Hover (types and engrave doc strings), document symbols (outline view).
3. v0.8.2 – Completion (keywords, in-scope identifiers, methods on the receiver type), goto definition.
4. v0.8.3 – Semantic-tokens highlighting; the TextMate grammar becomes a bootstrap fallback.
5. v0.8.4 – Rename, plus broader workspace symbol search.

v0.9.0 — File I/O & OS Rituals

Deliberately sequenced after v0.7.0 so every API returns fate from day one. Native-only, cfg-gated; the playground answers these rituals with the same “not available here” error summon uses. Files are tomes:

• recite(path) -> fate — read a file into a rune.
• inscribe(path, rune) -> fate — write.
• banish(path) -> fate — delete; plus an existence check.
• Time rituals land here too, alongside the sandbox decision they share.

v0.10.0 — Module System

Import / export across files, designed together with the workspace-level LSP features (workspace symbols, cross-file goto) that motivate it.

• conjure "path/to/module"; — bring a module’s bestowed names into scope.
• bestow — mark an engrave / artifact / forge as exported.

Later

Items still in design — sequencing depends on what falls out of the cycles above.

• Bytecode VM (promoted: this is the performance path) – Compile the AST to a compact bytecode with a register or stack VM. Typical 10–50× over tree-walking, keeps the Wasm playground story simple, and — crucially — becomes the compilation target a future self-hosted AbySS compiler emits. Sequenced before any native backend.
• Native compilation (Cranelift first, LLVM if ever) – Only worth opening after the VM exists and the type system has settled (enums, generics); a native backend added earlier would need reworking with every language change. Cranelift is the natural first step in a Rust workspace; LLVM only if peak performance or broad target coverage becomes a real goal. AbySS’s mandatory type annotations keep this door open.
• familiar — first-class functions / closures (new) – A familiar is a bound spirit that captures its surroundings and serves its summoner: the perfect name for a closure. Not currently on any cycle, but self-hosting pressure (below) and stdlib ergonomics (sort with a custom comparator) both pull it forward.
• Generics + User-defined Sum Types (rite) – Parameterise functions and data with type glyphs, and lift fate / augury from special-cased artifacts to user-definable sum types. The v0.7.0 experience feeds this design.
• Interpreter Performance, Packaging, Distribution – beyond the VM: debugging hooks, and a package story once modules have settled.

Self-hosting Milestones

The long-term flagship goal is an AbySS toolchain written in AbySS. It arrives in stages, and each stage doubles as a stress test of the cycles above:

Stage	Milestone	Unblocked by
0	Self-lexing — an AbySS tokenizer for AbySS source	v0.6.x strings + v0.7.0 fate / augury
1	Self-formatting — align reimplemented in AbySS	v0.9.0 file I/O, v0.10.0 modules, rite enums
2	Self-interpreting — an AbySS interpreter in AbySS, running (slowly) on the Rust interpreter	Stage 1 + familiar closures
3	True self-hosting — Stage 2 at practical speed, targeting the bytecode VM	the VM; realistically post-1.0

Track progress via the GitHub issue tracker or the project CHANGELOG.