Lispex Interpreter and Lispex VM

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

TaskInputRequired products
Compare tree and bytecode with compare-enginesSourceNative

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.

LISPEX
(+ 20 22)

Run it with the default Lispex Interpreter.

SH
lispex answer.lspx

Output

OUTPUT
42

Now select Lispex VM. A VM executes prepared instructions called bytecode.

SH
lispex run --backend rust --engine vm answer.lspx

Output

OUTPUT
42

Both 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 implementationRecorded procedure entriesRecord
LIL205/205Complete procedure table at that stage
Initial LIT84/205Initial implementation record
Later Topaz LIT contract v7205/205The contract's recorded current count
Lispex LIT consumer contract v2204/205The 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 productsComparable resource observations
Lispex Interpreter and Lispex VMOutput 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 informationWhat it identifies
Runtime implementationInterpreter family and versioned execution method
InvocationReproducible command or framed request protocol
Artifact identifierExact executable, WASM, and connecting-code bytes
Source and producer recordDeclared source and how the product was built
Resource profileNamed limits and reported usage counters
Compared casesExact 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.

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.

CompletionOutput and status
SuccessOutput and values, status 0
Ordinary runtime errorOutput already produced by earlier forms is retained, status 1
Resource limit reachedEmpty 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.