MeTTa Programming Language+MeTTa Programming Language Deep Dive+Language Stack and Implementations

The Language Stack

MeTTa sits within a multi-layer compilation stack described in the whitepaper (§3):

• MeTTa — High-level declarative pattern-rewrite language for AtomSpace manipulation
• MeTTa-IL — Intermediate representation derived from Graph-Structured Lambda Theory (GSLT) for compilation and optimization. Targets multiple backends (MORK, Rholang, JAX, Rust kernels). Maintains two GSLTs: fine-grained (implementation) and coarse-grained (developer-facing types) with proven correspondence.
• MORKL / MM2 — Low-level kernel operations running directly on MORK's data structures. MM2 uses Gather-Process-Scatter with priority-based execution for factor-graph message passing, weighted sweeps, and tensor operations.
• PyMeTTa (proposed) — Python-compatible surface transpiling to MeTTa-IL, enabling notebook-driven development, LLM-assisted coding, and integration with the Python ecosystem via the metta-magic library.

System Interfaces

• AtomSpace: MeTTa operates directly over AtomSpaces via the Space API. Programs can target specific Spaces (local, distributed DAS, neural) by naming them.
• Python: The hyperon Python library provides bidirectional MeTTa-Python interop. Grounded atoms can wrap Python objects and callable code.
• ASI Chain: MeTTa compiles to Rholang via MeTTa-IL for decentralized, capability-secured execution on F1R3FLY.
• MORK: PeTTa connects to MORK via FFI; MeTTa-IL routes local low-latency execution to MORK.

Implementation Anchors

• Hyperon Experimental (reference) — Rust implementation with deep Python integration via C API. Prioritizes flexibility and semantic correctness.
• PeTTa — High-performance Prolog-based compiler with Smart Dispatch. Execution speed comparable to handwritten Prolog. Connects to MORK backend. Recent stdlib additions (2026-05/06): alpha-unique-atom (alpha-equivalence dedup via unification) and a Tabling library exposing SWI-Prolog tabling for automatic memoization (naive Fibonacci ~1s→~50ms). Because PeTTa compiles on add-atom (vs hyperon-experimental's interpretation), calling a function defined later in execution needs an explicit reduce/recompile — the main remaining semantic gap. (MeTTa Study Group 2026-06-12; lib/lib_tabling.metta, examples/test_alpha_unique_atom.metta at HEAD 2026-06-05.)
• MeTTaLog — Prolog-native dual runtime (Douglas Miles / logicmoo), the most feature-complete non-Rust MeTTa. A SWI-Prolog interpreter is the default run path, with an opt-in MeTTa→SWI-Prolog clause compiler/transpiler (compile defaults to false; "WAM" = SWI's WAM engine, not raw bytecode). Evaluation is Prolog-backtracking nondeterminism; hand-written S-expression reader; Prolog-hosted corelib stdlib; gradual/optional types; multi-space with RDF persistency; optional Python/Janus + Hyperon (hyperonpy) bridge, used as a compatibility test-oracle rather than runtime delegation (MeTTaLog is an independent re-implementation, not a Rust-Hyperon front-end). Distinct from PeTTa (a separate SWI-Prolog translator/dispatch effort) despite the shared Prolog host. Quirks at HEAD (vnamed 74dbe9b8): Q-1 reproduced (bind! token-registration, no reset) / Q-2 fixed (cond absent — if/case/switch) / Q-3 reproduced (multi-reduces catchall, staying on hyperon-experimental's side of the MeTTaTron specificity-filter divergence). (per a 2026-06-08 source-code review.)
• JeTTa — the cluster's first JVM-bytecode-compiled MeTTa runtime (Vitaly Khudobakhshov + Alexey Potapov). Unlike MeTTaTron (a Rust tree-walk interpreter despite its "compiler" name), JeTTa performs real JVM bytecode codegen: an ANTLR grammar (Jetta.g4) frontend feeds an ASM (org.objectweb.asm) backend that emits .class files, run via a compile-load-invoke REPL with a custom JVM Space/Matcher (extended per-call bindings, bang(!)-evaluation, assert* ground functions); gradual types; Kotlin-hosted stdlib. At HEAD (main e3849120, v0.5) it is compile-and-run; a fuller eval-as-runtime mode is emerging on the active khud/dev branch (32 commits ahead, 2026-06-06). Quirks: Q-1 not-applicable (no bind!/new-space surface) / Q-2 fixed (cond absent, uses if) / Q-3 reproduced (multi-reduces catchall, staying on hyperon-experimental's side of the MeTTaTron divergence). (per a 2026-06-08 source-code review.)
• MeTTa-Morph — Macro-based MeTTa to Chicken Scheme translator achieving ~100× speedups. Compiles to C and native machine code. Provides bidirectional Scheme/C FFI: MeTTa code can call Scheme library functions and inline C via Chicken's foreign-safe-lambda, enabling integration with existing high-performance codebases. The compile! API allows in-session compilation from files, strings, or tuples.
• MeTTaTron — F1R3FLY-native Rust runtime with Tree-Sitter parser, MORK/PathMap storage layer, and Tokio-based threading. At HEAD efee4be (2026-01-19, Cargo v0.2.0, 190 commits ahead of the v0.2.0 Git tag), the repo name "MeTTa-Compiler" overstates current capability: the compile function parses tree-sitter output into a MettaState AST without code generation, and execution is an iterative trampoline tree-walk interpreter (compilation tracks live on unmerged feature branches feature/wam-backend, feature/jit-compiler, pr17/bytecode-vm, pr20/jit-codegen). Performance optimizations include 242.9× type lookup speedup (lazy cached subtrie), 10.3× fact insertion speedup (direct byte conversion bypassing string serialization), and indexed rule lookup (1.6–1.8×). Commit 9d7ea4b (2025-12-29) replaced PathMap-based multiset set operations (union-atom, intersection-atom, subtraction-atom, unique-atom) with HashMap-based ones, with empirical 3.5–5.3× speedup across dataset sizes 10–100,000; PathMap is retained for rule/fact/atom/type storage and MORK pattern-match queries. Rule matching filters to MOST-SPECIFIC rules only (src/backend/eval/mod.rs:1023+), suppressing catchall rules when a more-specific rule matches — a documented divergence from the hyperon-experimental v0.2.10 multi-reduction semantic. Provides synchronous and asynchronous Rholang integration via direct Rust linking (no FFI) through the shared f1r3node/models protobuf types. Targets MeTTa-IL for ASI Chain execution. (per a 2026-05-13 source-code review.)
• MeTTa-IL — Intermediate-language / formal-semantics track built on Graph-Structured Lambda Theory (GSLT); a runtime peer of the cluster only loosely (it implements IL semantics, not a MeTTa surface). At HEAD (F1R3FLY-io/MeTTaIL 3343fbe, on the dev branch — main is ~10 months stale and 180 commits behind dev; frmlbytecode is the active-work branch to 2026-03-30), the GSLT pipeline is a BNFC-generated Scala interpreter (Scala 3.4.1 + BNFC + Java parser-jar two-stage build); the hypercube transform pass is partial. Four sub-projects: Scala IL + GSLT + MeTTaIL-Gillespie (Rust stochastic simulator) + MeTTaIL2Matrix (Rust graph→triangular-matrix, GPU backend not wired). Multi-backend targeting (MORK / JAX / Rust kernels) remains roadmap-level; Rholang via the .module format is the HEAD-actual target. (per a 2026-05-15 source-code review.)
• FormalMeTTa — Demo-grade Scala reference for the preliminary (2023) MeTTa spec by Adam Vandervorst. Useful as a language-semantics reference, but partial: library only (no CLI runner) and carries unimplemented ??? holes (e.g. RewriteRules.scala:136), so spec coverage is incomplete; archival / low-activity. (per a 2026-05-15 source-code review.)

Module System

MeTTa's module system (Hyperon Experimental) encapsulates execution contexts: each module has a unique Space and Tokenizer, with the &self token resolving to the module's own Space. Modules form a hierarchical namespace using : as separator (e.g., top:mod1:sub_a), where top is always the root module. The same loaded module instance can appear at multiple points in the hierarchy via aliasing.

Three import modes are supported:

• import module as name — Import entire module under an alias
• import * from module — Import all symbols into the current Space
• import item from module as name — Import specific items

Module name resolution follows a priority chain: (1) already-loaded modules in the current context, (2) explicit entries in the module's PkgInfo (version requirements, file paths, remote URLs), (3) registered Catalogs searched in priority order. Default catalog search paths include the module's own resource directory, the hyperon/exts/ directory (Python environment), and an OS-specific config directory. Modules can be loaded from single .metta files, directories containing a module.metta file, or Python modules (.py files or packages with __init__.py). The PkgInfo structure (analogous to Cargo.toml) specifies metadata and dependency requirements. Export visibility and cross-module tokenizer import semantics are still under development.

(Provenance: repo-doc, hyperon-experimental docs — module system developer guide)