Quartz v5.25

Moonshots

Far-future ideas that require fundamentally different approaches or execution models. These are NOT on the roadmap. They’re here because they’re fascinating and might inform long-term direction.


Automatic Parallelism via Interaction Nets (Bend/HVM2)

Write normal recursive/functional code; the runtime automatically parallelizes across all CPU/GPU cores. No threading APIs, no async, no mutexes.

How it works: Programs are represented as graphs with typed ports (interaction nets). Rewrite rules reduce the graph, and the critical property is confluence — the order of reductions doesn’t matter. This means every reduction can be parallelized without locks or atomics.

Results: Bend achieved 57x speedup on RTX 4090 with zero parallel annotations. A bitonic sort that takes 12s single-threaded runs in 0.2s on GPU with no code changes.

Why it’s a moonshot for Quartz: This is a fundamentally different execution model from LLVM IR’s SSA-based sequential semantics. Would require a completely new backend compiling to an interaction net representation. Essentially building a second runtime and a second compiler backend.

Practical takeaway: Even if we never adopt the full model, the principle — that pure/functional subsets of a language can be automatically parallelized — could inform MIR-level analysis. If we can identify pure functions at compile time (which effect tracking would enable), we could auto-parallelize them via conventional fork-join without interaction nets.

Based on: Yves Lafont’s Interaction Combinators (1997). A mathematically elegant model that waited 25 years for hardware capable of exploiting it.

Languages:

  • Bend (Higher Order Company) — Python-like syntax, compiles to HVM2
  • Vine (2025) — Experimental, compiles to Ivy/IVM, adds borrowed references

References: Bend, Vine, Interaction Calculus


Verse-Style Transactional Computation

Simon Peyton Jones + Tim Sweeney’s language (Epic Games) where all computation is transactional. Expressions can fail, and failure triggers automatic rollback.

Why it’s wild: Unifies error handling, backtracking search, pattern matching, and concurrency into one paradigm. Logic programming falls out naturally from the failure/backtracking model. Designed for multiplayer game server scale.

Why it’s a moonshot: Needs write-ahead log and rollback mechanism fundamentally at odds with LLVM’s sequential memory model. The transactional semantics require a runtime that can snapshot and restore program state.

Practical takeaway: A lighter version — failable blocks with choice expressions that try alternatives — could be implemented as syntactic sugar over existing pattern matching and error handling.

References: Verse at SPLASH 2024, Verse VM at ICFP 2025


Full Dependent Types

Types that depend on values. The program’s type system becomes a proof system. Lean4 and Idris2 are the state of the art.

Why it’s a moonshot: Requires a fundamentally different type checker (bidirectional, with unification over open terms). Error messages become proofs. Compilation becomes theorem proving. The entire programming experience changes.

Practical takeaway: Refinement types (which we ARE implementing) are the pragmatic subset of dependent types. They give 80% of the value with 20% of the complexity.

References: Lean4, Idris 2


Language Server Protocol (Full LSP)

A production-quality LSP server written in Quartz itself. Go-to-definition, hover docs, autocomplete, rename symbol, find all references.

Why it’s a moonshot: Requires incremental compilation infrastructure (the compiler currently recompiles everything). Also needs persistent state across edits (a project database). This is months of work, not weeks.

Practical takeaway: A basic LSP that shells out to quartz --dump-ast for diagnostics is achievable in days (and is part of Phase W). The full incremental version is the moonshot.


Package Manager & Registry

A full package ecosystem: quartz.toml manifest (already exists), dependency resolution, a central registry, versioned publishing, reproducible builds.

Why it’s a moonshot: The module system has known constraints (no top-level var, cross-module enum refs). A package manager that works well requires a solid module system first. Also needs a registry service, auth, CDN — infrastructure work.

Practical takeaway: quartz init / quartz build (Phase W.7) is the seed. The package manager grows from that.


Self-Hosted in WASM (Browser-Native Compiler)

Compile the entire self-hosted Quartz compiler to WASM. Run it in the browser. Users compile Quartz code without installing anything — the compiler itself runs client-side.

Why it’s a moonshot: The self-hosted compiler uses file I/O, malloc, and platform-specific features. WASI handles some of this, but a smooth browser experience requires rearchitecting the compiler’s I/O layer to work with browser APIs (virtual filesystem, streaming output).

Practical takeaway: The C bootstrap compiled to WASM via Emscripten is the pragmatic path for a browser playground (Phase W). The self-hosted-in-WASM version is the ultimate statement.