Roadmap

Roadmap

No package in this repository has had a stable release yet, and the language itself is still settling — see the repository README for where the language grammar stands. This page is about something narrower: which implementations of tramaj exist, and which are wanted next.

Where things stand today

Five independent implementations target the same grammar and are checked against a shared, language-neutral conformance corpus — template/context/expected-output triples that both must reproduce byte-for-byte, per case, in both concrete and symbolic evaluation modes. That’s a deliberately strong bar: a case belongs in the corpus only if independently written implementations can run it identically.

None is published to a package registry yet (see the README’s “Publishing” section) — all are used today as workspace, source or git dependencies. Each has its own changelog page and Atom feed. See Integrating tramaj for what’s actually usable from each right now, including the fold each one does or doesn’t ship.

The native-implementation wish list is done

Earlier versions of this page asked for native JavaScript, Python and Rust implementations, so that hosts in those ecosystems would get what PureScript and Haskell hosts already had: an in-process parser and evaluator, with no subprocess and no JSON round-trip just to get a Node. All three exist now — tramaj-js, tramaj-py and tramaj-rs — and each passes the full corpus in both modes, v3 and v4 extensions included.

Desired next: folds, and releases

• Folds. Only PureScript (tramaj-halogen) and JavaScript (tramaj-react) ship a fold to a rendering target. A DOM fold for JS, a fold to a common Python templating output, and a fold for at least one Haskell or Rust UI or markup library are the obvious next pieces.
• Registry releases. The crates.io, npm and PyPI packages are ready to publish but not published; the PureScript registry and Hackage are deliberately deferred until the API has settled. Releases happen when there are major changes, and each package’s version tracks the language version it implements in its major digit.

This is a wish list, not a schedule: there’s no committed timeline or assigned owner for any of it.

What “done” looks like for a new implementation

tramaj-hs, tramaj-rs, tramaj-js and tramaj-py are the templates to follow, since they were added after the language had settled on a normative spec and output format (tramaj-py is the smallest: one module per concern, standard library only). A new implementation is considered on par with the existing ones once it:

• implements the grammar and evaluation rules in reference.md, including the static restrictions that make imports, action keys, and ctx(...) paths analyzable without evaluation (see Properties);
• encodes and decodes the Node AST exactly per node-json.md, including the round-trip guarantee (decode(encode(n)) == n);
• passes every case in the conformance corpus, in both concrete and symbolic mode, byte-for-byte against expected.json;
• optionally, but ideally: a fold analogous to tramaj-halogen’s foldToHalogen for at least one popular rendering target in that ecosystem (e.g. a DOM fold for JS, a common Python templating output for Python).

The v3 (?/!, v3-symbols.md) and v4 (%, v4-types.md) extensions are both shipped and part of the same conformance bar — a new implementation isn’t considered complete while targeting only the v2 core.

Contributing an implementation

If you’re taking on one of these, the corpus is the fastest way to find out what you got wrong: it’s meant to be run against a from-scratch implementation just as it’s run against the five that exist, and a case that byte-for-byte matches all of them today is a strong signal your evaluation semantics agree with theirs. Open an issue on the repository before investing heavily in one — coordinating on which language is being worked on avoids duplicate effort.