Compare Lispex implementations to investigate differences in results, output, and diagnostics. Use the implementation table to choose a comparison for your program. These implementations are called runtime implementations.
Native includes the Lispex Interpreter and Lispex VM. For ordinary rule execution, start with Run Lispex in Your Application.
Choose the comparison
| Task | Input | Required products |
|---|---|---|
Compare tree and bytecode with compare-engines | Source | Native |
Use the comparison reference to choose the report and read its outcome. Bytecode and Deployment covers saving and running bytecode.
Run the same source with two engines
Save this complete program as answer.lspx.
(+ 20 22)Run it with the default Lispex Interpreter.
lispex answer.lspxOutput
42Now select Lispex VM. A VM executes prepared instructions called bytecode.
lispex run --backend rust --engine vm answer.lspxOutput
42Both commands exit with status 0 and create no files.
For the VM command, Native builds and checks the bytecode before executing it.
The default engine, tree, is Lispex Interpreter.
It reads the source, normalizes shorthand into core forms (CoreExpr), and evaluates those forms.
Source execution and retired implementations
The Lispex Interpreter runs source in Native, npm, WASM, and the Playground. Native also supplies the Lispex VM for verified bytecode.
Both engines are implemented in Rust. Earlier documentation calls them Rust tree interpreter and Rust VM.
The CLI keeps --backend rust and --engine tree|vm as its identifiers.
LIL and LIT retirement
LIL and LIT completed their role in internal cross-validation. They were retired in Lispex 1.21 to reduce future maintenance costs. Current execution and application integration use Lispex Interpreter and Lispex VM and the separate decision and full-profile evaluators.
The former Topaz VM and AOT public companions belong to earlier releases.
Topaz VM was a separate executor for Lispex bytecode. AOT compiled Lispex through Topaz into a native program.
Lispex VM is the current built-in executor, identified by lispex-rust-vm/v1; the former Topaz VM used lispex-topaz-vm/v1.
The internal Lispex VM continues to execute verified bytecode and powers the embed evaluators.
LIL was a separate interpreter written in Lispex, with its own reader, normalization, and evaluation running on the Rust interpreter. LIT was a Lispex interpreter written in Topaz. Their source, research records, receipts, and versioned artifacts remain available as historical material.
| Historical implementation | Recorded procedure entries | Record |
|---|---|---|
| LIL | 205/205 | Complete procedure table at that stage |
| Initial LIT | 84/205 | Initial implementation record |
| Later Topaz LIT contract v7 | 205/205 | The contract's recorded current count |
| Lispex LIT consumer contract v2 | 204/205 | The consumer's recorded baseline |
These counts refer to the 205 registry rows marked profile-required at the time of each record.
Keep each original result with its source, runner, and contract version.
The v1.20 engine reference preserves the earlier installation and comparison guidance.
Bytecode implementations
Lispex VM (lispex-rust-vm/v1) is included in Native.
It runs bytecode produced by the Rust source frontend and Core IR compiler.
Core IR is an intermediate representation that resolves name references.
Native converts the complete current language profile to the prescribed lispex.core-ir/v1 format and validates it.
Inspection shows variable cells, captured variables, tail positions, requirements, source locations, and identifiers.
The compiler converts validated Core IR to lispex.bytecode/v1.
The verifier checks the bytecode before creating VM state.
Lispex VM implements all 205 built-in procedure entries.
The 18 entries that call user procedures use iterative VM state machines to manage those calls.
Read results and resource usage
Comparison reports record results, resource usage, and source and producer information in separate fields. The selected execution method keeps its own error and resource status. Reports are written atomically to a new path.
Read semantic differences separately from resource differences. Semantic observations include status, primary code, message, output, values, warnings, and diagnostics.
| Compared products | Comparable resource observations |
|---|---|
| Lispex Interpreter and Lispex VM | Output bytes and completed roots |
The Lispex Interpreter uses its own depth model. Historical source-interpreter comparisons checked the resource outcome and require all five usage fields to be present. They retained each implementation's usage counts separately when comparing outcomes. Procedure support counts and resource usage counters answer different questions. Use the resource reference for counter definitions.
Identifying the product in a comparison
| Recorded information | What it identifies |
|---|---|
| Runtime implementation | Interpreter family and versioned execution method |
| Invocation | Reproducible command or framed request protocol |
| Artifact identifier | Exact executable, WASM, and connecting-code bytes |
| Source and producer record | Declared source and how the product was built |
| Resource profile | Named limits and reported usage counters |
| Compared cases | Exact input collection, interpreter family, target, and host variant |
These fields let you determine which product and execution conditions produced a comparison. Bytecode and Lispex VM describes the instruction format and execution details.
Read earlier comparison records
The historical comparison record covers 144 named cases. It identifies the Rust, LIL, and LIT executables used, their resource profiles, results, and reruns. Those cases describe the inputs that were executed. The procedure tables describe implementation coverage against a different denominator.
Keep the original report with its input, catalog, products, and version-matched tools. See Compare Engine Results for the historical record's scope.
Related product features
For application calls, the evaluator reference describes the separate decision and full-profile evaluators. For trusted-source evaluation and fixed comparisons from an editor, see Native MCP.
Compiled Lispex Vouch
Compiled Lispex Vouch uses the Lispex VM.
Native creates a source-bound lispex.vouch-compiled-artifact/v1 file and authenticates the request.
It derives Core IR and bytecode again from the exact source selected by the recipient.
It records current tree and Meaning agreement, compares the verified Lispex VM result, and passes the result to the local gate.
Interactive output across products
Native, npm, public WASM, and the Playground use the same interactive output rules. They read the entire source and expand shorthand into core forms before evaluation. They then display explicit output and each successful form's value in order.
| Completion | Output and status |
|---|---|
| Success | Output and values, status 0 |
| Ordinary runtime error | Output already produced by earlier forms is retained, status 1 |
| Resource limit reached | Empty output, one resource diagnostic, status 2 |
Browser results expose output, diagnostics, ok, and exit_status.
Input, Output, and Permissions shows the output behavior.
Native also supplies formatting and the local MCP authoring service. VS Code and Open VSX extensions delegate Format Document to the installed Native binary. MCP uses local standard input and output for language reference, the procedure registry, trusted-source evaluation, diagnostics, and fixed engine comparisons. Its evaluator applies declared byte and time limits. See the CLI reference for commands and results.