MeTTa Programming Language+MeTTa Programming Language Full+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.
• JeTTa — JVM/Kotlin compiler leveraging JVM multithreading and custom Space implementations.
• 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. (MeTTa runtime cluster pilot Source 3, closed 2026-05-13.)
• MeTTa-IL — Intermediate language implementation with GSLT foundation.
• FormalMeTTa — Literal Scala implementation of the preliminary MeTTa spec, useful as a reference for language semantics.

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)