MeTTa Implementations

Scope

Repositories that implement the MeTTa language (compilers, interpreters, formal specifications), MeTTa developer tooling, and MeTTa execution services. For the language design and formal semantics, see MeTTa Programming Language.

Active Repositories

Repo	Language	Execution Model	Maturity	Purpose
hyperon-experimental	Rust + Python + C	Interpreter (reference)	Operational	Official reference MeTTa implementation (v0.2.10). Deep Python integration via C API. PyPI: pip install hyperon.
PeTTa	SWI-Prolog	Prolog WAM compilation	Operational	High-performance compiler with Smart Dispatch. Execution speed comparable to handwritten Prolog. MORK FFI integration. Recent stdlib additions (2026-05/06): alpha-unique-atom (alpha-equivalence dedup via unification) + a Tabling library exposing SWI-Prolog tabling for automatic memoization (naive Fibonacci ~1s→~50ms).
metta-wam (MeTTaLog)	SWI-Prolog + Python	Interpreter (default) + opt-in compiler	Operational	Prolog-native dual runtime: interpreter is the default run path, with an opt-in MeTTa→SWI-Prolog clause compiler/transpiler (compile defaults to false). "WAM" = runs on SWI-Prolog's WAM engine, not raw bytecode emission. Hand-written Prolog S-expression reader; Prolog-hosted corelib stdlib; gradual/optional types; optional Python/Janus + Hyperon (hyperonpy) bridge (not Rust delegation); multi-space with RDF persistency scaffolding; REPL, LSP, Jupyter kernel. Most feature-complete non-Rust MeTTa runtime. Default branch vnamed at HEAD 74dbe9b8 (master is a stale divergent legacy branch). Quirks: Q-1 reproduced (bind! token-registration, no reset) / Q-2 fixed (cond absent) / Q-3 reproduced (multi-reduces catchall — stays on hyperon-experimental's side of the MeTTaTron divergence). See MeTTa runtime cluster pilot Source 5, closed 2026-06-08.
jetta (JeTTa)	Kotlin / JVM	JVM bytecode (ANTLR + ASM)	Operational (pre-1.0)	The cluster's first JVM-bytecode-compiled MeTTa runtime: ANTLR grammar (Jetta.g4) frontend + ASM (org.objectweb.asm) backend emitting real .class bytecode. Compile-load-invoke REPL on main; custom JVM Space/Matcher with extended per-call bindings; gradual types; Kotlin-hosted stdlib. v0.5 on main (HEAD e3849120); active "eval-as-runtime" development on the khud/dev branch (32 commits ahead, HEAD d2cd57c 2026-06-06). Authors Vitaly Khudobakhshov + Alexey Potapov. Quirks: Q-1 not-applicable (no bind!/new-space surface) / Q-2 fixed (cond absent, uses if) / Q-3 reproduced (multi-reduces catchall — stays on hyperon-experimental's side of the MeTTaTron divergence). See MeTTa runtime cluster pilot Source 6, closed 2026-06-08.
metta-morph	Chicken Scheme	Macro translation	Operational	MeTTa-to-Scheme translator achieving 10–200× speedup. Compiles to native binaries via csc.
MeTTaTron	Rust	Tree-walk interpreter + Tokio batch async	Experimental (main stagnant, branches active)	F1R3FLY-native runtime targeting Rholang via direct Rust linking. Tree-sitter parser; iterative trampoline evaluator; HashMap for multiset set-ops, MORK/PathMap for rule storage and pattern-match queries. At HEAD efee4be (2026-01-19) the compile function is parse-to-state, not code generation — compilation work lives on unmerged feature branches. Rule matching filters to most-specific rules (divergent from hyperon-experimental v0.2.10 catchall semantics). Requires nightly Rust and sibling MORK/PathMap/f1r3node checkouts. See MeTTa runtime cluster pilot Source 3, closed 2026-05-13.
MeTTa-IL	Scala 3.4.1 + BNFC + Rust	GSLT tree-walk interpreter	Experimental	Intermediate-language / formal-semantics track, not a direct MeTTa runtime peer. BNFC-generated Scala interpreter; GSLT grammar + interpreter + hypercube transform (partial); Scala 3.4.1 + BNFC + Java parser-jar two-stage build. Four sub-projects: MeTTaIL (Scala IL) + GSLT + MeTTaIL-Gillespie (Rust stochastic simulator) + MeTTaIL2Matrix (Rust graph→triangular-matrix, GPU target not wired). Default branch dev at HEAD 3343fbe (2026-03-02); main ~10 months stale (2090611, 2025-07-08, 180 commits behind dev); frmlbytecode branch the active-work signal to 2026-03-30 (e61f075). See MeTTa runtime cluster pilot Source 4, closed 2026-05-15.
mettail-rust	Rust (PraTTaIL + Ascent)	Macro-generated Ascent (Datalog) rewrite engine	Experimental (active)	Rust-native, clean-sheet parallel successor to the Scala MeTTa-IL — related by GSLT operational-semantics vision, not by shared code. The language! proc-macro generates a PraTTaIL (Pratt + recursive-descent) parser (LALRPOP removed), a Rust-enum AST, and an Ascent rewrite engine per formal calculus; rho-calculus (RhoCalc) is the first-class demo language. Real pathmap trie dependency (Adam Vandervorst's crate) scoped to RhoCalc literal/trie ops — a shared dependency, not a MORK merge. Carries a complete machine-checked Rocq/Coq proof suite (12 .v files, 0 Admitted / 124 Qed) over its rule-consolidation + Ascent-optimization transforms. Default main at HEAD a95726a (2026-05-20), active main + live branches (cost-accounting, modules); GSLT2rho compile path is branch-only. Zar Goertzel's zariuq/mettail-rust fork (268 behind upstream) carries Lean-export + tree-sitter feature branches. IL/formal-semantics track, not a direct MeTTa runtime peer. See SC-4 Cross-Org Cognitive Repo Sweeps Source 1, closed 2026-06-09.
FormalMeTTa	Scala 3	Spec-reference (partial)	Experimental (archival)	Demo-grade reference for the preliminary (2023) MeTTa spec by Adam Vandervorst. Library only — no CLI runner. Partial coverage: carries unimplemented ??? holes (e.g. RewriteRules.scala:136), so spec behavior is incomplete; low-activity / archival. Author identity overlaps the HAA concept-blending category-theoretic thread as cross-cluster context only, not a code dependency. See MeTTa runtime cluster pilot Source 4, closed 2026-05-15.
atomspace-metta	C++ / Scheme	ForeignAST bridge (classical AtomSpace)	Archival (2023)	Archival classical-AtomSpace bridge stub by Linas Vepstas (all commits 2023-05-11; ~3 years stale). Maps only function declarations onto the classical C++/Scheme AtomSpace via ForeignAST (MettaAST.cc + encode/decode) — NOT the Hyperon MeTTa runtime/Space. Core MeTTa semantics (match/unification, ground, multivalued propagation) are pickaxe-confirmed never implemented at HEAD. On the Perception pilot's AtomSpace-Scheme side of the two-stack split, not the MeTTa-runtime side. See MeTTa runtime cluster pilot Source 6, closed 2026-06-08.
metta-lsp	TypeScript	N/A (tooling)	Operational	VS Code LSP extension with Tree-sitter parsing, go-to-definition, hover, completion, rename, formatting.
vspace-metta	MeTTa / Prolog / Python	Version Space + MeTTaLog	Operational	Version Space Candidate Elimination in MeTTa with FlyBase bio data integration (56M+ atoms). Includes REPL and Jupyter kernel.
MettaWamJam	SWI-Prolog / Python	HTTP REST service	Operational	Lightweight web REPL and REST API for MeTTa via PeTTa transpiler. Docker-ready. Optional MORK/FAISS/PyTorch integrations.
metta-testsuite	MeTTa / Python	N/A (test infrastructure)	Operational	Cross-implementation compatibility test suite with CI, JUnit conversion, and nightly reports. Tests Hyperon, MeTTaLog, MORK, metta-morph.
metta-prebuilt-binary	Rust	N/A (tooling)	Operational	Prebuilt MeTTa binaries plus metta-run CLI with output formatting and install scripts.
metta-catalog	JSON	N/A (tooling)	Operational	Official JSON registry of public MeTTa modules for package discovery and resolution.
jupyter-petta-kernel	Python	N/A (tooling)	Operational	Jupyter kernel for executing MeTTa code via PeTTa in notebook environments.

How They Fit Together

The implementations form a convergent family — multiple execution strategies targeting the same language semantics:

• hyperon-experimental is the reference interpreter: prioritizes correctness and Python interop. All other implementations target semantic compatibility with it.
• PeTTa is the performance path for symbolic workloads: Prolog's native backtracking and unification give it speed advantages for logic-heavy tasks. Connects to MORK via mork_ffi. Unlike hyperon-experimental's interpreter, PeTTa compiles on add-atom, so reflexive/self-modifying code that calls a function defined later needs an explicit reduce or recompile — the main remaining behavioural gap between the two (MeTTa Study Group 2026-06-12).
• metta-wam shares the Prolog substrate with PeTTa but emphasizes bidirectional execution and probabilistic reasoning.
• jetta brings MeTTa to the JVM ecosystem: useful for Android, Java-heavy organizations, and JVM multithreading.
• metta-morph is the native compilation path: AWK preprocessing → Python autoquoting → Chicken Scheme → optional C compilation. Best for batch computation where startup cost is amortized.
• MeTTaTron + MeTTa-IL are the ASI Chain path: MeTTa → MeTTa-IL (GSLT) → Rholang → F1R3FLY. Not yet production-ready. At HEAD efee4be MeTTaTron is a tree-walk interpreter with tree-sitter parsing and direct-Rust Rholang integration via the shared f1r3node/models protobuf types; the "compiler" framing in the repo name applies to the unmerged feature-branch roadmap (WAM backend, JIT, bytecode-VM), not to main. Notable runtime divergence from hyperon-experimental: rule matching filters to most-specific rules (suppressing catchalls), where v0.2.10 returns both. Multiset set operations (union-atom, intersection-atom, subtraction-atom, unique-atom) moved from PathMap to HashMap in 2025-12-29 with empirical 3.5–5.3× speedup; PathMap retained for rule/atom storage and MORK pattern-match queries.
• FormalMeTTa is a specification artifact, not a production runtime — useful for verifying language semantics.
• atomspace-metta is a bridge experiment — the only path from MeTTa to the classical C++ AtomSpace. Currently partial.
• vspace-metta is a MeTTaLog application layer — Version Space learning with FlyBase bio data, demonstrating large-scale (56M+ atoms) MeTTa execution.
• MettaWamJam is a deployment surface — a Docker-ready REST API exposing PeTTa execution over HTTP, useful for web integration and agent access.

Quick Start

Fastest path to running MeTTa code:

# Option 1: Python (reference implementation)
pip install hyperon
python -c "from hyperon import MeTTa; m = MeTTa(); print(m.run('!(+ 1 2)'))"

# Option 2: PeTTa (high-performance, requires SWI-Prolog 9.3.9+)
cd PeTTa && sh run.sh ./examples/fib.metta

# Option 3: MeTTaLog (WAM-based, requires SWI-Prolog with Janus)
source ./INSTALL.sh --allow-system-modifications
mettalog --repl

# Option 4: JeTTa (JVM, requires JDK 17+)
cd jetta && ./gradlew build && ./gradlew run

# Option 5: MeTTa-Morph (native compilation, requires Chicken Scheme)
cd metta-morph && sh run_scheme.sh examples/fib.metta

Current State vs. Whitepaper

• MeTTa-4 semantic model (whitepaper §3): Under development. No implementation has finalized MeTTa-4 semantics yet — hyperon-experimental and PeTTa are the closest.
• MeTTa-IL compilation pipeline: MeTTaIL exists but is experimental. The full MeTTa → MeTTa-IL → MORK/Rholang routing described in the whitepaper is not yet operational end-to-end.
• PyMeTTa transpilation: Proposed in the whitepaper but no implementation exists yet.
• Cross-implementation convergence: The metta-testsuite repo provides shared test cases, but behavioral differences between implementations remain.

Forks and Mirrors

Most repos target distinct execution strategies rather than forking a single codebase. Known mirrors and variant relationships:

• PeTTa / metta-wam: Both use SWI-Prolog but with different compilation strategies (Smart Dispatch vs. WAM bidirectional execution).
• metta-morph: A local mirror tracks a ngeiswei fork of the canonical trueagi-io/metta-morph.
• metta-wam: Local mirrors track contributor forks of trueagi-io/metta-wam (patham9, ngeiswei, zariuq). Per Source 5 (2026-06-08) all three are stale relative to the canonical vnamed branch: patham9 and zariuq are fully behind (zero fork-only commits); ngeiswei shares no merge base with vnamed (unrelated import histories), so its raw "ahead" count is a history artifact, not active forward work — none should be read as a divergent tradition.
• vspace-metta: Fork of logicmoo/vspace-metta, locally tracking patham9's variant.

Recommended Entry Points

• New to MeTTa: Start with pip install hyperon and the metta-examples repo.
• Performance-sensitive workloads: Use PeTTa with MORK FFI.
• JVM ecosystem: Use jetta.
• Language semantics research: Read FormalMeTTa's Scala source alongside the MeTTa Specification.
• VS Code development: Install metta-lsp extension.

Gaps and Consolidation Opportunities

• No unified test suite enforcement: metta-testsuite exists but implementations don't run it in CI consistently.
• atomspace-metta is incomplete: The C++ AtomSpace bridge lacks match/unification — the core operations needed for real MeTTa execution.
• PyMeTTa doesn't exist yet: The Python transpilation layer described in the whitepaper has no implementation.
• Windows support varies: hyperon-experimental has limited Windows Python packages; MeTTaTron explicitly doesn't support Windows; metta-wam has a separate INSTALL.bat.