Roadmap

Where we are today

Capa is a working alpha. It compiles, type-checks, transpiles to Python, and runs. Every example in this site, in the examples directory, and in the white paper is executable. The boundary between what is real and what is roadmap is sharp:

v0.2, public readiness

The bridge from "working alpha" to "shareable alpha". All three pieces have landed; tagging and flipping the repository to public is the last step.

• DONE
  "Capa would have caught X" demo, event-stream

  A safe Capa version of the flat_map function whose JavaScript counterpart shipped a Bitcoin-wallet exfiltrator in 2018. Attack-attempt code shown rejected by the analyzer with source-aligned errors. Lives in examples/demo_event_stream.capa + docs/demo-event-stream.md.

• DONE
  VSCode syntax highlighting

  TextMate grammar covering all keyword categories, with built-in capabilities highlighted distinctly. String interpolation, numeric literals in all bases, operators including .., ..=, =>, ?. Lives in vscode/; install via symlink / junction. Marketplace publication after the public flip.

• DONE
  Public-facing website

  A five-page static site (Home, Why Capa, Language tour, Get started, Roadmap). No JS, no framework, no external fonts. Designed to serve directly from GitHub Pages.

• NEXT
  Tag v0.2.0-alpha and flip the repository public

  One git tag and one gh repo edit --visibility public. After that, ship governance documents (CONTRIBUTING, CHANGELOG, issue templates, SECURITY.md).

The road ahead

White-paper promises still open

• P1
  Generic attenuation

  Extend the Net.restrict_to pattern to the other built-in capabilities: Fs.restrict_to(path_prefix), Env.restrict_to_keys([...]), Clock.restrict_to_after(t), and similar. The runtime infrastructure for narrowing is already in place; this is mostly per-capability API design and tests.

• P3
  Native module system

  The keyword import is parsed but analyzer-rejected today. A proper design needs paths, visibility, cyclic-import rules, and a deterministic resolution algorithm. Practical win is small while projects are single-file; the v1 cut may ship without it.

• P3
  Refinement types

  Marked as future in the white paper, a way to express, in the type system, properties like "this string is non-empty" or "this list is sorted". Research-grade; not in scope for a 1.0.

EBNF declares but not implemented

• P2
  Doc comments (///, /**)

  Lexer currently treats them as ordinary comments. Implement preservation through the AST and a tiny capa-doc generator. ~4-6 hours.

• P2
  Raw strings (r"...")

  Useful for regular expressions and Windows paths. ~1-2 hours.

• P2
  Named arguments

  Syntax exists in the EBNF; analyzer needs to map argument names to parameter positions correctly and reject duplicates. ~1-2 hours.

Tooling that moves the adoption needle

• P1
  Language server (LSP)

  The single biggest multiplier for any new language. Python implementation using pygls: diagnostics first, then hover, then go-to-definition. ~1-2 weeks for a useful subset.

• P1
  Formatter (capa-fmt)

  Canonical and non-configurable, gofmt-style. Walks the AST and re-emits. ~1-2 days for v1.

• P2
  capa init

  Project scaffolding command. ~1-2 hours, but waits on the module system to be useful.

• P3
  Package manager / registry

  Only meaningful once there is a module system and a plausible audience. Out of scope for v0.2 / v0.3.

Known limitations

• P1
  Multi-line match inside parentheses

  Parentheses currently suppress significant newlines, so f(match x ... ) with multi-line arms does not parse. Workaround is an inline { } block. ~1-2 hours to fix.

• P2
  ? operator uses an internal exception

  Correct but slower than an expanded early-return at the transpiled level. Optimisation; no semantic change.

PhD-aligned work

Capa as an artefact in the SBOM-Governance thesis. Not language work, but research that uses the language.

• P1
  SPDX 2.3 parser written in Capa

  Proves Capa can interoperate with the real SBOM format. Becomes a thesis chapter on representation. ~1 week.

• P1
  CycloneDX 1.5 parser written in Capa

  Same story for the second mainstream SBOM format.

• P1
  User-defined capability Provenance

  A capability representing the right to query / verify a piece of supply-chain metadata. Demonstrates user-defined caps in a concrete domain.

• P1
  SBOM ↔ capability linking

  A Capa program that reads an npm package's SBOM and checks whether the declared capabilities of its dependencies match what static analysis of their source code says they actually need. The "auditable supply chain" pitch, made concrete.

Explicitly not planned for v1

For honesty and scope control:

• LLVM backend. Was Phase 4 of the original white-paper roadmap. Far future; not a priority while Python is a perfectly serviceable target.
• Self-hosting. Was Phase 5. Very far future. The compiler is unlikely to be rewritten in Capa before there is a working Capa community.
• Full async / await. Reserved keywords exist; no implementation. Async semantics that interact correctly with capabilities is a real research question and a large lift.
• Tail-call optimisation. The transpiler emits regular Python calls; recursion is bounded by the CPython stack.
• Garbage collection beyond CPython's. Capa inherits whatever the Python runtime gives it.
• Custom syntax extensions / macros. Capa is a fixed grammar by design. The discipline depends on the analyzer being able to read every program completely.