T32 Lsp Mcp Server

Simple Language

[Production Ready] [Tests] [LLVM Cross] [License]

Simple is a self-hosted language and toolchain that combines a readable Python-like surface with compiler-integrated testing, documentation, architecture rules, and baremetal-oriented execution paths.

The repo is unusually broad: language, compiler, interpreter, loader, test runner, doc generation, traceability tooling, SDN-backed project databases, editor tooling, and hardware-oriented test flows all live together.

Quick Navigation: Distinctive Features | Feature Status | Quick Start | Language Basics | Examples | Editor Plugins | Documentation

Distinctive Features

• Self-hosted staged toolchain: real source layers for frontend, type analysis, borrow checking, backend, driver, interpreter, and loader live in-tree.
• Verification-native workflow: SSpec tests, the SPipe runner/docgen process, SDoctest executable docs, coverage, traceability checks, and generated spec docs are part of the toolchain rather than bolted on.
• MDSOC architecture support: virtual capsules, manifests, and architecture-aware repository structure are first-class concepts.
• Parser-friendly macro system: macro definitions, expansion, validation, and hygiene are compiler features rather than editor-hostile text substitution.
• Math-oriented syntax blocks: m{}, loss{}, and nograd{} are implemented syntax with parsing, evaluation, five rendering backends (text, debug, Unicode, LaTeX, Markdown), and editor integration (query/LSP hover, VSCode highlighting/preview, Neovim inline Unicode preview with conceal). The autograd path is complete for the promoted torch-backed C/LLVM scope.
• SDN-backed textual databases: tests, todos, dashboards, and other project metadata are stored through repo-native SDN data flows.
• Multiple execution paths: interpreter, loader, SMF/module loading, and native/LLVM-oriented compilation paths coexist in one system.
• Baremetal-oriented build and test plumbing: QEMU, semihosting, MMIO mailbox, remote baremetal flows, and adapter-backed hardware lanes (8 authoritative) are built into the repo story.
• Tooling-aware language rules: Tree-sitter integration, primitive-public-API linting, traceability tooling, and language statistics are part of the platform.
• Shared UI contract across supported surfaces: one HTTP-based test protocol (Protocol V1) with UITestClient drives both the web backend and the TUI-web proxy through a shared handle_test_request handler, verified by a cross-surface contract suite. Contract: doc/04_architecture/shared_ui_contract.md

Feature Status Highlights

Implemented and safe to advertise:

• SSpec tests, SPipe runner/docgen, SDoctest, coverage, traceability checks, and generated spec docs
• SPipe mock policy: system-test mock ban, HAL-only and custom pattern modes
• Self-hosted staged compiler, interpreter, and loader architecture
• MDSOC manifests and architecture-focused project structure
• Parser-friendly macros with validation and hygiene
• Tree-sitter outline/query tooling
• SDN-backed project, test, and todo databases
• Primitive-public-API linting and semantic wrapper/unit-type patterns
• Borrow-checking infrastructure
• Watch mode and auto-build support
• mmap-backed loader support and executable-memory plumbing
• Baremetal build/test plumbing and host-aware remote baremetal flows
• C/C++ bidirectional SFFI for the supported ABI subset: exports, imports, callback trampolines, layout verification, and round-trip proof tests

Implemented, but best described with qualifiers:

• LLVM full-family closure is complete for the declared public matrix: every llvm-lib and llvm backend row is now explicitly stable or unsupported, with no ambiguous middle states. rust-llvm remains a bootstrap-only seed path outside the public family claim
• Lean verification workflow is complete for the supported verification subset: deterministic Lean generation, proof artifact inventory, Lean/Lake checking, cache invalidation, and verification-state reporting. Contract: doc/04_architecture/lean_verification_contract.md. Report: doc/09_report/lean_verification_complete_2026-04-04.md
• GC and no-GC runtime families: 5 public families (common, nogc_sync_mut, nogc_async_mut, gc_async_mut, nogc_async_mut_noalloc) with compiler boundary enforcement, interpreter warnings, and target preset mapping. Support matrix: doc/04_architecture/runtime_family_support_matrix.md
• Shared UI contract across web backend and TUI-web proxy (Protocol V1): shared handler, structured error model, stable element IDs, cross-surface contract suite — but this is a shared test protocol, not a full unified UI rendering layer
• Remote baremetal execution has 8 authoritative lanes (3 stable + 5 host-aware including both GHDL semihost and mailbox simulation), but hardware-dependent lanes remain host- and board-aware rather than universally complete. Lane matrix: doc/08_tracking/lane_matrix.md

Implemented with bounded scope:

• m{} / loss{} / nograd{} are complete for the promoted torch-backed C/LLVM scope, including backward, detached-input failure, and nograd{} restore semantics. Other backends remain deferred
• AOP provides predicate-based pointcuts (execution, within, attr), deterministic before/after/around advice, compile-time weaving as the default backend, and scoped runtime interception. Support matrix: doc/05_design/aop_support_matrix.md
• VHDL backend compiles a documented hardware-oriented Simple subset to synthesizable VHDL-2008, validated through GHDL analysis/elaboration. Strict fail-fast on unsupported constructs. Two GHDL RV32 simulation lanes are operational: semihost (GDB-backed, ARM semihosting traps) and mailbox (debugger-independent, MMIO at 0x80FF0000 with ram_sentinel result collection). Support matrix: doc/04_architecture/vhdl_support_matrix.md. Mailbox protocol: doc/04_architecture/ghdl_rv32_mailbox_protocol.md

Implemented:

• Anti-dummy / anti-stub enforcement is active on the primary source and compiled CLI surfaces (simple lint, simple verify quality). All public-facing proof suites (SFFI, T32 hardware, compiler/runtime/system) now pass the gate. Remaining debt is only in deferred OS/GPU/experimental areas — all active surfaces are clean.

See doc/report/unique_features.md for the evidence-backed audit.

Runtime Families

Simple organizes its standard library into runtime families based on allocation, mutation, and concurrency requirements:

The compiler enforces family boundaries: importing a GC module from a no-GC context produces a diagnostic warning. Target presets (Baremetal, Hosted, EmbeddedWithHeap) automatically restrict module resolution to compatible families.

For advanced use: nogc_async_immut provides persistent data structures with lock-free concurrency.

See Runtime Family Support Matrix for full contracts, and Known Limitations for current caveats.

Quick Start

Installation

What you get:

• Complete Simple compiler and toolchain source
• Standard library and generated spec manuals
• Development tools, including MCP server, LSP, and debugger surfaces

Use a source checkout for the current beta. It also initializes the example and tooling submodules used by the docs and tests:

git clone --recurse-submodules https://github.com/ormastes/simple.gitcd simpleexport PATH="$PWD/bin:$PATH"simple --version

For an existing checkout:

git submodule sync --recursivegit submodule update --init --recursive

Note: Rust remains present as the bootstrap seed and host substrate. Product compiler, library, and tool work should stay in Simple source wherever the repo can express it; do not read "pure Simple" as "there is no Rust source in this checkout" today.

Source Footprint

Snapshot generated 2026-04-23 from existing tracked .spl, .rs, .c, .h, .s, .S, and .asm files. Blank lines and comment-only lines are excluded; examples/ code is included; vendored and third-party source is excluded.

From Source (Developers Only)

Only needed if you want to modify the runtime:

scripts/setup/setup.shsbin/simple build bootstrap

Direct commands behind the wrapper:

src/compiler_rust/target/bootstrap/simple --versionbin/simple build bootstrapsha256sum bootstrap/simple_stage2 bootstrap/simple_stage3

See doc/02_requirements/app/build/bootstrap.md and doc/03_plan/compiler/bootstrap/pure_simple_bootstrap_stage2_remaining_2026-05-04.md for the current bootstrap flow and remaining pure-Simple self-hosting notes.

Build with GPU Support

simple build --release --features=vulkan

Your First Program

# hello.spl>>> fn main() -> i64:...     0  # Entry point, returns exit code

# Run itsimple hello.splecho $?  # Prints: 0

CLI Usage

The simple command works like Python:

Usage:  simple                      Start interactive REPL  simple <file.spl>           Run source file  simple <file.smf>           Run compiled binary  simple -c "code"            Run code string; statement snippets print only program output  simple compile <src> [-o <out>]  Compile to SMF  simple watch <file.spl>     Watch and auto-recompile
Build System (Self-Hosting):  simple build                Build the project (debug)  simple build --release      Release build (optimized)  simple build --bootstrap    Bootstrap build (minimal 9.3MB)  simple build test           Run all tests  simple build coverage       Generate coverage reports  simple build lint           Run linter (clippy)  simple build fmt            Format code (rustfmt)  simple build check          Run all quality checks  simple build clean          Clean build artifacts  simple build --help         Show all build options
Options:  -h, --help     Show help  -v, --version  Show version  -c <code>      Run code string  --gc-log       Enable verbose GC logging  --gc=off       Disable garbage collection

Examples

# Interactive REPLsimple>>> 1 + 23>>> x = 10>>> x * 550>>> exit
# Run a programecho "main = 42" > hello.splsimple hello.splecho $?  # Exit code: 42
# Compile to binarysimple compile hello.splsimple hello.smf  # Run the compiled binary
# Watch mode (auto-recompile on changes)simple watch app.spl

Language Basics

Variables & Types

# Variables - immutable by default, mutable with var>>> x = 10>>> x10>>> var y = 20>>> y20>>> PI = 3.14159>>> PI3.14159
# Type inference works automatically>>> count = 100>>> count100
# Basic types inferred>>> a = 42>>> a42>>> pi = 3.14159>>> flag = true>>> flagtrue
# String interpolation default>>> name = "world">>> msg = "Hello, {name}!">>> print msgHello, world!

Control Flow

# If/else with indentation>>> var x = 5>>> if x > 0:...     print "positive"... elif x < 0:...     print "negative"... else:...     print "zero"positive
# Loops>>> for i in 0..3:...     print i012
>>> while x > 3:...     x = x - 1>>> x3

Functions

>>> fn add(a: i64, b: i64) -> i64:...     a + b  # Implicit return
>>> fn greet(greeting: text):...     print "Hello, {greeting}!"
# Function calls>>> sum = add(1, 2)>>> sum3>>> greet("Alice")Hello, Alice!
# Lambdas with backslash>>> double = \x: x * 2>>> nums = [1, 2, 3, 4, 5]>>> evens = nums.filter(\x: x % 2 == 0)>>> evens[2, 4]

Structs & Classes

# Structs (value types)struct Point:    x: f64    y: f64
p = Point(x: 1.0, y: 2.0)
# Classes (reference types)class Person:    name: text    age: i64
    fn greet():        print "Hi, {self.name}!"
alice = Person(name: "Alice", age: 30)alice.greet()

Collections

# Arrays - short form (no val)>>> nums = [1, 2, 3, 4, 5]>>> first = nums[0]>>> first1
# Collection methods>>> count = nums.len()>>> count5
# Dictionary (short form)>>> scores = {"alice": 100, "bob": 85}>>> alice_score = scores["alice"]>>> alice_score100
# Filter with lambda>>> odds = nums.filter(\x: x % 2 == 1)>>> odds[1, 3, 5]>>> big_nums = nums.filter(\x: x > 3)>>> big_nums[4, 5]
# Tuples>>> pair = (1, "hello")>>> num = pair.0>>> num1>>> msg = pair.1>>> msg"hello"
# List comprehensions>>> squared = [x * x for x in 0..5]>>> squared[0, 1, 4, 9, 16]>>> evens = [x for x in nums if x % 2 == 0]>>> evens[2, 4]

Unit Types (Postfix Literals)

Type-safe units prevent mixing incompatible values:

# Define measurement unit families with postfix syntaxunit length(base: f64):    mm = 0.001, cm = 0.01, m = 1.0, km = 1000.0
unit velocity(base: f64) = length / time:    mps = 1.0, kmph = 0.2777777777777778, mph = 0.44704# The standards-backed catalog records km/h canonically as kilometre / hour# with exact factor 5/18 relative to m/s.
# Define nominal wrappers with postfix syntaxnewunit UserId: i64 as uidnewunit OrderId: i64 as oid
# Usage with postfix literalsheight = 175_cm              # Length typewidth = 10_cm + 5_mm         # Auto-converts to same basespeed = 200_kmph             # Velocity typedistance = 42_km             # Length type
# Type safety - compile error:# bad = height + speed       # Error: can't add Length + Velocity
# Semantic IDs prevent mix-upsuser = 42_uid                # UserIdorder = 100_oid              # OrderId# wrong: UserId = 100_oid    # Error: OrderId ≠ UserId
# Computed unitstravel_time = distance / speed    # Returns Time typeprint("ETA: {travel_time.to_min()} minutes")

Pattern Matching

enum Shape:    Circle(radius: f64)    Rectangle(width: f64, height: f64)    Square(side: f64)    Triangle(base: f64, height: f64)
# Pattern matching with case syntaxfn area(s: Shape) -> f64:    match s:        case Circle(r):            3.14159 * r * r  # Implicit return        case Rectangle(w, h):            w * h        case Square(side):            side * side        case Triangle(b, h):            0.5 * b * h
# Preferred arrow syntax (shorter)fn perimeter(s: Shape) -> f64:    match s:        | Circle(r) -> 2.0 * 3.14159 * r        | Rectangle(w, h) -> 2.0 * (w + h)        | Square(side) -> 4.0 * side        | Triangle(a, b, c) -> a + b + c
# Pattern matching with nil (not None)fn get_radius(opt: Option<f64>) -> f64:    match opt:        | Some(r) -> r        | nil -> 0.0  # Use nil instead of None

Parser-Friendly Macros

Simple macros are contract-first and LL(1) parseable - the IDE can provide autocomplete without expanding the macro:

# Macro declares what it introduces in the contract headermacro define_counter(NAME: Str const) -> (  returns result: (init: Int, step: Int),  intro counter_fn: enclosing.class.fn "{NAME}Counter"(start: Int) -> Int):  const_eval:    const init = 0    const step = 1
  emit counter_fn:    fn "{NAME}Counter"(start: Int) -> Int:      start + step
# Usage - IDE knows about UserCounter before expansionclass Demo:  define_counter!("User")
  fn run() -> Int:    self.UserCounter(10)  # Autocomplete works!

Built-in macros:

# Print with formattingprintln!("Hello, {name}!")           # Print with newlineprint!("Value: {x}")                 # Print without newline
# Debug output with source locationdbg!(expression)                     # Prints: [file:line] expression = value
# Assertionsassert!(condition)                   # Panic if falseassert_eq!(a, b)                     # Panic if a != bassert_ne!(a, b)                     # Panic if a == b
# Collectionsnums = vec![1, 2, 3, 4, 5]           # Create vectorformatted = format!("x={x}")         # Format string without printing
# Panic with messagepanic!("Something went wrong: {err}")

Const-unrolled macro (generate multiple functions):

# Generate accessor functions for each axismacro gen_axes(BASE: Str const, N: Int const) -> (  intro axes:    for i in 0 .. N:      enclosing.class.fn "{BASE}{i}"(v: Vec[N]) -> Int):  emit axes:    for i in 0 .. N:      fn "{BASE}{i}"(v: Vec[N]) -> Int:        v[i]
# Usage: generates x(), y(), z() accessorsclass Point3D:  gen_axes!("axis_", 3)  # Creates axis_0, axis_1, axis_2

AOP & Aspect-Oriented Programming

Predicate-based pointcuts with compile-time weaving as the default execution model:

# Before advice — runs before matching functionson pc{ execution(* handle_request(..)) } use log_entry before priority 10
# After advice — runs after successful returnon pc{ execution(* save(..)) & attr(audited) } use audit_write after_success priority 20
# Around advice — wraps function with proceed() contracton pc{ within(services.*) } use trace_around around priority 50
# Architecture rules — enforce layer dependencies at compile timeforbid pc{ within(hal.*) } "HAL cannot depend on services"allow  pc{ within(services.*) } "Services can use HAL"

Supported selectors: execution(*), within(*), attr(*) with & (AND), | (OR), ! (NOT) operators. Advice kinds: before, after_success, after_error, around (proceed exactly-once). Ordering: priority (descending) > specificity > lexicographic name. Zero overhead: no weaving metadata when no aspects are defined. Runtime interception: scoped, opt-in only, disabled in release builds.

See AOP Support Matrix for the full contract.

SDN Configuration

Simple Data Notation - a minimal, token-efficient format for config files:

# app.sdn - Application configurationapp:    name: MyService    version: 2.1.0
server:    host: 0.0.0.0    port: 8080    workers: 4
# Inline arrays and dictsfeatures = [auth, logging, metrics]database = {driver: postgres, host: localhost, port: 5432}
# Named tables - compact tabular datarate_limits |endpoint, requests, window|    /api/login, 5, 60    /api/search, 100, 60    /api/upload, 10, 300

Load SDN in Simple:

config = sdn::load("app.sdn")print("Server port: {config.server.port}")

SDoctest

Executable examples are part of the maintained test surface. Simple supports both demonstration blocks and verified sdoctest blocks, with sdoctest intended for examples that must run and match output.

>>> factorial(5)120>>> factorial(0)1

## Stack data structure with LIFO semanticsstruct Stack:    items: [i64]
var s = Stack(items: [])s.items.push(1)s.items.push(2)print s.items.len()  # 2

Run SDoctest examples:

simple test --sdoctest README.md      # Run verified examples in Markdown/docssimple test --spl-doctest src/math.spl # Run file-local source-comment doctestssimple test --sdoctest --tag slow     # Filter by tag

--doctest is still accepted as a compatibility alias, but --sdoctest is the clearer name for the implemented path. In the canonical release command, the positional test selects the spec tree only. --whole still discovers Markdown from config/sdoctest.sdn and comment sdoctests from the production src/lib, src/compiler, and src/app roots.

Functional Update Operator (->)

# The -> operator calls a method and assigns result backvar data = load_data()data->normalize()        # data = data.normalize()data->filter(min: 0)     # data = data.filter(min: 0)
# Chainingdata->normalize()->filter(min: 0)->save("out.txt")

GPU Computing

import std.gpu
# GPU kernel style 1: #[gpu] with explicit bounds check#[gpu]fn vector_add_kernel(a: []f32, b: []f32, result: []f32):    idx = gpu.global_id(0)           # Global thread index    if idx < len(result):        result[idx] = a[idx] + b[idx]
# GPU kernel style 2: @simd with auto bounds handling@simdfn vector_scale(data: []f32, scale: f32):    val i = this.index()             # Global linear index (same as gpu.global_id())    data[i] = data[i] * scale        # Bounds auto-handled
# Host function - runs on CPUfn main():    device = gpu.Device()
    # Allocate and upload data    a = [1.0, 2.0, 3.0, 4.0]    b = [5.0, 6.0, 7.0, 8.0]
    buf_a = device.alloc_buffer(a)    buf_b = device.alloc_buffer(b)    buf_result = device.alloc_buffer<f32>(4)
    # Launch kernel    device.launch_1d(vector_add_kernel, [buf_a, buf_b, buf_result], 4)
    # Download results    device.sync()    result = device.download(buf_result)    # result = [6.0, 8.0, 10.0, 12.0]

GPU Thread Indexers:

#[gpu]fn matrix_multiply(A: []f32, B: []f32, C: []f32, N: u32):    # Multi-dimensional indexing    val row = gpu.global_id(0)       # First dimension    val col = gpu.global_id(1)       # Second dimension
    # Thread group (workgroup) info    val local_row = gpu.local_id(0)  # Index within workgroup    val group_row = gpu.group_id(0)  # Workgroup index
    # Alternative @simd style    # val(row, col) = this.index()  # Tuple for 2D    # vallocal_idx = this.thread_index()    # valgroup_idx = this.group_index()
    if row < N and col < N:        var sum = 0.0_f32        for k in 0..N:            sum += A[row * N + k] * B[k * N + col]        C[row * N + col] = sum

GPU Examples: See examples/gpu/vulkan/ for vector add, matrix multiply, reduction, and image blur.

Documentation

Quick Links by Topic

Core Documentation

Getting Started:

• Documentation Hub - Current entry point for the numbered doc tree
• Getting Started - Project setup and first steps
• Syntax Quick Reference - Canonical public syntax cheat sheet
• Testing Guide - Testing workflow and command surface

Language Reference:

• Syntax Guide - Surface syntax and examples
• Type System Guide - Types, mutability, and usage
• Module System Guide - Imports, packages, and layout
• Standard Library Guide - Stdlib organization and usage

GPU Computing:

• Deep Learning Guide - Pure Simple, model-oriented, and training flows
• GPU Programming Guide - Backend and kernel-oriented GPU usage
• GPU API - API-level GPU reference
• LLVM Backend Architecture - Backend implementation details

Development:

• Build Guide - Building Simple and common workflows
• Testing Guide - Test runner behavior and flags
• SSpec Scenario Manual Guide - step(...), inline scenarios, capture, and generated manual style
• Mock Policy Guide - System test mock ban and test level enforcement
• Coverage Guide - Coverage, SDoctest, and enforcement
• MCP Tooling Guide - MCP registration and usage

Advanced Features:

• Macro System - Executable macro spec and status
• AOP Support Matrix - Supported selectors, advice kinds, backends, and error codes
• SDN Format - Note/SDN storage and indexing format
• SDoctest - Documentation testing and verified examples
• Feature Documentation - Generated feature-doc artifact format

Examples

Deep Learning Examples

Simple ships multiple deep learning examples across pure-Simple, model-training, and GPU-oriented flows:

Pure Simple Neural Networks:

# XOR neural network trainingbin/simple examples/pure_nn/xor_training_example.spl
# Linear regression (learns y = 2x + 1)bin/simple examples/pure_nn/simple_regression.spl
# Iris flower classificationbin/simple examples/pure_nn/iris_classification.spl

MedGemma Korean Fine-Tuning:

# Progressive LoRA training to prevent catastrophic forgettingbin/simple examples/medgemma_korean/run_all.spl

CUDA Programming:

# Direct CUDA C API - multi-GPU, streams, eventsbin/simple examples/cuda/basic.spl

See Deep Learning Guide for current documentation.

Other Examples

The examples/ directory contains additional working examples:

Run an example:

bin/simple examples/cli_demo.spl

SSpec Scenario Manuals

Feature and system documentation is generated from executable SSpec .spl scenarios. SPipe is the related runner/docgen process; SSpec is the authoring style: write readable step("...") actions, keep executable assertions in the same scenario, and let docgen render compact manual steps with folded source.

Example 1: TUI Selection

This follows the real Code Actions picker flow exercised by test/03_system/gui/editor_controller_spec.spl: populate a selectable panel, choose a row, and apply it with Enter. Keep the interaction and its visible selection contract together.

use std.spec.{describe, expect, it, step}
describe "Code action picker":  it "selects and applies the requested repair":    # @req REQ-EDITOR-CODE-ACTION-001    val actions = [      ["First fix", "Rename first now"],      ["Second fix", "Rename second now"]    ]    step("Open the Code Actions menu")    step("Select \"Second fix\"")    val selected_index = 1    step("Press Enter to apply the selected action")    expect(actions[selected_index][0]).to_equal("Second fix")    expect(actions[selected_index][1]).to_equal("Rename second now")

Generated operator manual:

1. Open the Code Actions menu2. Select "Second fix"3. Press Enter to apply the selected action

Example 2: Tabular Output

This is shortened from the dashboard HTML rendering system spec at test/03_system/feature/app/web_dashboard/dashboard_render_spec.spl. It is the same table-shaped contract useful for compression, storage/NVMe, security, and HTML test reports: stable columns, representative rows, and assertions over the generated surface.

use std.spec.{describe, expect, it, step}use app.dashboard.render.table.{render_html_table}
describe "Artifact verification table":  it "renders each artifact result as a table row":    val headers = ["Artifact", "Integrity", "Status"]    val rows = [      ["firmware.bin", "sha256", "passed"],      ["policy.sdn", "signature", "blocked"]    ]    step("Render the artifact verification table")    val html = render_html_table(headers, rows)    step("Verify the blocked policy result remains visible")    expect(html).to_contain("policy.sdn")    expect(html).to_contain("blocked")

Generated QA evidence can retain the compact tabular result:

Artifact     | Integrity | Statusfirmware.bin | sha256    | passedpolicy.sdn   | signature | blocked

Given_*, When_*, and Then_* helper naming is legacy style. Use step("...") for new SSpec manuals. See the SSpec Scenario Manual Guide.

Generated docs land in the numbered documentation tree under doc/06_spec/. Docgen mirrors a test path without its leading test/ component; for example, test/03_system/plan_acceptance/evidence_showcase_spec.spl generates doc/06_spec/03_system/plan_acceptance/evidence_showcase_spec.md.

Grammar & Specification

Language Grammar

Simple’s current language references are split between the guide tree for user-facing explanations and the spec tree for executable or generated reference material.

Current Reference Documents:

• Syntax Quick Reference - Fast public-language reference
• Syntax Guide - User-facing language walkthrough
• Language Spec Index - Current generated spec index
• Syntax Spec - Spec artifact for syntax coverage
• Types Spec - Spec artifact for type-system coverage
• Modules Spec - Spec artifact for module-system coverage

Quick Grammar Reference:

# Top-levelprogram ::= statement*
# Statementsstatement ::= function_def | class_def | struct_def | enum_def            | import_stmt | export_stmt | expr_stmt
# Expressions (Pratt parser)expr ::= literal | identifier | binary_op | unary_op       | call | index | field_access | lambda       | if_expr | match_expr | block
# Typestype ::= identifier | array_type | tuple_type | fn_type       | optional_type | result_type | generic_type
# Literalsliteral ::= integer | float | string | bool | array | dict | tuple

Specification Index

The current spec and guide material is organized under the numbered documentation tree:

Core Language:

• Syntax Spec - Syntax-oriented spec material
• Types Spec - Type-system spec material
• Data Structures Spec - Data-structure coverage
• Functions Spec - Functions and pattern matching
• Traits Spec - Traits and implementations
• Memory Spec - Ownership and borrowing
• Modules Spec - Import/export system

Advanced Features:

• Concurrency Spec - Async and concurrency behavior
• Metaprogramming Spec - Macros and decorators
• Macro Spec - Macro-specific executable coverage
• Capability Effects - Capability/effect system
• Standard Library Guide - Stdlib structure and usage
• SFFI Guide - Interop guidance
• External Native Libraries - Optional host-library integration

Testing & Tooling:

• Testing Guide - Test runner and matchers
• SSpec Scenario Manual Guide - Scenario manuals generated from executable specs
• Coverage Guide - Coverage and SDoctest enforcement
• Lint Guide - Lint rules and workflow
• MCP Guide - MCP workflow and registration

GPU & Platform:

• GPU Programming Guide - GPU usage
• Deep Learning Guide - Model-oriented examples
• Baremetal Guide - Platform and baremetal flows

See doc/README.md, doc/06_spec/README.md, and doc/07_guide/README.md for the current documentation entry points.

Project Structure

simple/├── bin/                      # CLI wrappers and admitted binaries│   ├── simple                # Main CLI│   └── release/              # Release binaries by target│├── src/                      # Product source│   ├── app/                  # CLI, build, MCP, LSP, test runner, tools│   ├── compiler/             # Numbered compiler layers│   │   ├── 00.common/        # Shared compiler contracts and cache keys│   │   ├── 10.frontend/      # Lexer, parser, AST, desugaring│   │   ├── 50.mir/           # Lowered intermediate representation│   │   ├── 70.backend/       # Native, LLVM, C, WASM, and linker backends│   │   ├── 80.driver/        # Build driver and incremental cache│   │   │   └── cache/reference/ # Reverse-reference scheduling and receipts│   │   ├── 95.interp/        # Interpreter execution layer│   │   └── 99.loader/        # Module resolution, loading, and JIT instantiation│   ├── compiler_rust/        # Rust seed bootstrap compiler│   ├── lib/                  # Standard library, imported as use std.X│   ├── runtime/              # Native runtime and support libraries│   └── verification/         # Formal verification│├── test/                     # Executable specifications│   ├── 01_unit/              # Unit tests│   ├── 02_integration/       # Integration tests│   ├── 03_system/            # System and feature tests│   ├── 04_smoke/             # Fast product smoke tests│   └── 05_perf/              # Performance tests│├── doc/                      # Numbered lifecycle documentation│   ├── 01_research/          # Research│   ├── 02_requirements/      # Requirements│   ├── 03_plan/              # Plans│   ├── 04_architecture/      # Architecture│   ├── 05_design/            # Detail design│   ├── 06_spec/              # Generated/manual SSpec documents│   └── 07_guide/             # User and contributor guides│├── .scv/quarantine/          # Ignored local SCV/JIT/root artifacts└── build/                    # Ignored output, bootstrap artifacts, and scratchpad probes

Incremental Compile and Interpreter Boundaries

The reverse-reference records under src/compiler/80.driver/cache/reference/ map changed declarations and artifacts to their known consumers. The build driver uses them to select invalidation and reuse candidates; the loader uses the same dependency facts for scheduling. They make incremental compilation more selective when receipts and cache keys match, but do not alter language semantics or turn an interpreter run into a native compilation. Interpreter execution remains owned by src/compiler/95.interp/.

The admission model and current evidence limits are documented in the reverse-reference harmonization plan.

Development

Building

# Debug buildsimple build
# Release buildsimple build --release
# With GPU supportsimple build --release --features=vulkan
# Bootstrap build (minimal 9.3MB)simple build --bootstrap

Testing

Full-suite snapshot (2026-02-14): 4,067/4,067 passing

Simple uses a broad test strategy spanning spec tests, SDoctest, coverage, and system lanes. The counts below are from the linked 2026-02-14 report:

# All tests (4,067 tests in 17.4 seconds)simple test
# Run specific test filesimple test path/to/spec.spl
# With verbose outputsimple test --verbose
# Coverage reportssimple build coverage

Test Coverage:

• Core interpreter: 227 tests
• Compiler: 306 tests
• Standard library: 428 tests
• Applications: 142 tests
• Libraries (ML, Physics, Game): 185 tests
• Integration & Coverage: 2,779 tests

Performance:

• Total execution: 17.4 seconds
• Average per test: 4.3ms
• All tests deterministic and fast

Performance Profiles:

• Language profile: scripts/check/check-cross-language-perf.shs generates doc/09_report/cross_language_perf_2026-06-06.md
• GUI profile: tools/gui_perf_bench/run_all_benchmarks.shs generates doc/09_report/gui_perf_benchmark_2026-06-06.md
• Startup/TUI profile: scripts/check/check-startup-size-performance-audit.shs records TUI startup rows in doc/09_report/startup_size_performance_audit_2026-05-27.md

See doc/09_report/session/full_test_suite_results_2026-02-14.md for detailed test analysis.

Code Quality

# Check before commit (fmt + lint + test)simple build check
# Full check (includes coverage + duplication)simple build check --full
# Format codesimple build fmt
# Lintsimple build lint

AI Tooling (MCP, LSP, Plugin)

Simple ships with MCP servers, LSP servers, and Claude Code plugins — all written in Simple.

Install Simple MCP Server

The Simple MCP server exposes repo-native tools for code diagnostics, VCS, build, test, debug, and related workflows. For current registration details, use the repo scripts and guide docs rather than relying on hardcoded counts here.

# From a repo checkout — register with Claude Codeclaude mcp add simple-mcp -- \  /absolute/path/to/simple/bin/simple \  /absolute/path/to/simple/src/app/mcp/main.spl
# Or use the project .mcp.json (auto-detected by Claude Code)sh config/mcp/install.shs

Install Simple MCP Plugin

The simple-mcp Claude plugin is a repo-checkout plugin. Install it from a Simple repository checkout; it is not a standalone portable runtime bundle.

claude plugin marketplace add tools/claude-plugin/marketplaceclaude plugin install simple-mcp@simple-local

The plugin launches bin/simple_mcp_server from the repository root.

Install Simple LSP Plugin

The Simple language server provides completions, hover, go-to-definition, diagnostics, and semantic tokens for .spl / .shs files.

# From a repo checkoutclaude plugin marketplace add tools/claude-plugin/marketplaceclaude plugin install simple-lsp@simple-local

Binary full path: bin/simple run src/app/lsp/main.spl

Install Both (Quick Setup)

cd /path/to/simple
# 1. MCP serversh config/mcp/install.shs
# 2. LSP pluginclaude plugin marketplace add tools/claude-plugin/marketplaceclaude plugin install simple-lsp@simple-local

Prompt Examples

Once the MCP server and LSP plugin are installed, try these prompts in Claude Code:

> "Run the linter on src/app/cli/main.spl and fix any warnings"
> "Show me all unused variables in the compiler frontend"
> "Run the unit tests for the SDN parser"
> "Build the project in release mode and show the result"
> "What does the function `parse_expression` in the parser do?"
> "Find all TODO items in the codebase"
> "Check the doc coverage for the standard library"
> "Debug why test/01_unit/lib/common/value_spec.spl is failing"

Editor Plugins

VSCode Extension

Full-featured extension with Tree-sitter highlighting, LSP integration, and math block support.

cd src/app/vscode_extensionnpm install && npm run compile && npm run packagecode --install-extension simple-language-0.1.0.vsix

Key features:

• Semantic syntax highlighting (Tree-sitter powered)
• LSP: completions, hover, go-to-definition, diagnostics
• Math block highlighting for m{}, loss{}, nograd{} with nested brace support
• Test CodeLens: "Run Test/File/Doctest" gutter arrows on describe/it/context/sdoctest blocks
• AI-powered completions and chat (requires GitHub Copilot)

See src/app/vscode_extension/README.md for full documentation.

Neovim Plugin

-- lazy.nvim{ "nicholasgasior/simple.nvim", ft = "simple", opts = {} }
-- Or from project checkoutvim.opt.rtp:prepend("/path/to/simple/src/app/nvim_plugin")require("simple").setup()

Key features:

• LSP integration with auto-detection
• Math block conceal with inline Unicode preview (frac(1,2) -> (1)/(2), alpha -> α, sqrt(x) -> √(x))
• Test lens: "Run" virtual text beside test blocks
• Tree-sitter queries (highlights, folds, text objects, injections)
• Brief view (fold to signatures)

See src/app/nvim_plugin/README.md for full documentation.

TRACE32 Tools

MCP servers, CMM language server, and CLI tools for Lauterbach TRACE32 debuggers. See examples/10_tooling/trace32_tools/README.md for full documentation.

The repo-managed container flow is headless and uses t32mciserver. It does not ship bundled TRACE32 GUI compatibility libraries; vendor runtime files must come from your local /opt/t32 installation.

Primary lifecycle wrapper:

scripts/t32q.shs buildscripts/t32q.shs onscripts/t32q.shs waitscripts/t32q.shs pingscripts/t32q.shs reopenscripts/t32q.shs off

GUI container reopen path:

scripts/t32q.shs gui-onscripts/t32q.shs gui-reopenscripts/t32q.shs off

gui-on uses the Docker/Podman TRACE32 GUI path with host X11 forwarding, so it requires a real host X11 session (DISPLAY, /tmp/.X11-unix, and usually XAUTHORITY). For quick diagnostics use:

scripts/t32q.shs doctor

Hello-world firmware smoke:

scripts/t32_semihost_hello.shs --board stm32wbscripts/t32_semihost_hello.shs --board stm32h7scripts/t32_semihost_hello.shs --board stm32wb --build-only

Optional: Install T32 MCP Servers

These TRACE32 MCP servers are not installed by the default project MCP setup. Register them manually only if you actively use TRACE32 tooling.

cd /path/to/simple
# T32 MCP — controls live TRACE32 debug sessions (23 tools)claude mcp add t32-mcp -- \  /absolute/path/to/simple/bin/simple \  /absolute/path/to/simple/examples/10_tooling/trace32_tools/t32_mcp/main.spl
# T32 LSP MCP — CMM script analysis, no hardware needed (6 tools)claude mcp add t32-lsp-mcp -- \  /absolute/path/to/simple/bin/simple \  /absolute/path/to/simple/examples/10_tooling/trace32_tools/t32_lsp_mcp/main.spl

Binary full paths:

• T32 MCP: bin/simple run examples/10_tooling/trace32_tools/t32_mcp/main.spl
• T32 LSP MCP: bin/simple run examples/10_tooling/trace32_tools/t32_lsp_mcp/main.spl

Install CMM LSP Plugin

claude plugin marketplace add tools/claude-plugin/marketplaceclaude plugin install cmm-lsp@simple-local

Binary full path: bin/simple run examples/10_tooling/trace32_tools/cmm_lsp/mod.spl --lsp

T32 Prompt Examples

> "Parse this CMM script and check for errors: config/t32/stm32h7_gdb_start.cmm"
> "Connect to TRACE32 on localhost:20000 and read the CPU registers"
> "Show me all labels and macros defined in my CMM script"
> "Convert this GUI PRACTICE script to CLI batch mode"
> "Check if my CMM script has any undefined macros or unreachable code"
> "Set a breakpoint at main, run to it, and show local variables"
> "What TRACE32 commands are available for memory access?"
> "Auto-complete suggestions for 'Data.LOAD' in my CMM script"

Contributing

See CLAUDE.md for development guidelines and AGENTS.md for AI agent instructions.

Documentation Structure:

• Specifications go in doc/06_spec/ (what the language supports)
• Guides go in doc/07_guide/ (how to use features)
• Research goes in doc/01_research/ (why/how decisions were made)
• Plans go in doc/03_plan/ (implementation roadmaps)
• Reports go in doc/09_report/ (session summaries and completion reports)

License

Apache License 2.0. See LICENSE.

Bundled third-party runtime components and redistribution notices are listed in THIRD_PARTY_NOTICES.md.

Release packages also include THIRD_PARTY_NOTICES.md.

Resources

Official Documentation:

• Documentation Hub - Entry point for the numbered docs tree
• Language Specification - Current spec index
• User Guides - Practical tutorials

Quick References:

• Syntax Quick Reference
• Type System Guide
• GPU Computing Guide

Development:

• Architecture Overview
• Feature Documentation
• Implementation Plans