Dust Programming Language

DPL — unified classical · quantum · phase computation

Dust Programming Language (DPL)

A clean-slate language designed from first principles to support classical, quantum, and phase-based computation in one coherent system—grounded in physical reality: resources, time, irreversibility, and global consistency are explicit and first-class.

v0.1 language definition
spec is canonical law
determinism + auditability
constraint-first execution

Regime-Typed Computation

Every executable process is explicitly in one regime: K (classical), Q (quantum), or Φ (phase). Regimes are interoperable, but boundaries are explicit and constrained.

Explicit Effects

Observation, emission, sealing, and coupling are never hidden. Effects define the observable boundary of execution and enable deterministic replay.

Admissibility as Gatekeeper

Computation proceeds only when global constraints are satisfied. Inadmissibility is explicit, terminal, and observable—never implicit “best effort.”

Design Principles

Small set · non-negotiable · enforced structurally

Core Principles

  • Explicitness over inference: nothing important is implied later.
  • Constraints before control flow: validity is global before progress is local.
  • Determinism as a requirement: observable behavior is reproducible and auditable.
  • Admissibility as gatekeeper: computation proceeds only inside admissible space.
  • Implementation independence: no compiler/runtime/back-end defines meaning.
  • Semantic stability: evolution preserves meaning over novelty.

Regimes

K — deterministic, time-aware computation
Q — linear, non-clonable resources
Φ — admissibility- and consistency-governed computation

Dust unifies these regimes by making constraints, resources, time, and effects first-class— while preserving strict boundaries where required.

Canonical Specification

/spec is authoritative

The Dust language is defined by the specification directory. If any implementation or document disagrees with the spec, the spec wins.

dustlang/ spec/ # Canonical language specification (LAW) charter/ # Authority, scope, admissibility ir/ # DIR: canonical semantic representation vm/ # DVM: reference execution semantics compiler/ # Compiler architecture & phase model semantics/ # Admissibility, effects, time semantics security/ # Security model verification/ # Formal verification hooks governance/ # Versioning & semantic stability research/ # Interpretive research (non-normative) guides/ # Examples, book, migration (non-normative)

Documentation Map

Normative vs non-normative

Normative

  • /spec — language law (canonical definition)
  • /charter — authority, scope, admissibility
  • /ir — DIR specification (canonical meaning)
  • /vm — DVM reference semantics (execution meaning)
  • /compiler — phase model and determinism guarantees
  • /semantics — admissibility, effects, time semantics
  • /security, /verification, /governance — trust, proof, stability

Non-Normative

  • DPL_White_Paper.md — vision & positioning
  • /research — interpretive framing (no authority)
  • /guides — examples, book, migration (illustrative only)
  • /archive — deprecated / inadmissible materials

Contributing

Meaning first · coherence always

Focus Areas

  • spec clarity and internal consistency
  • error discovery and correction
  • examples that illustrate semantics (without defining them)
  • tooling that preserves canonical meaning and determinism

Governance

Dust evolves under explicit governance to preserve semantic stability: meaning is defined by the spec; compatibility is enforced structurally; implementations do not create precedent.

Authority: charter/authority.md
Scope: charter/scope.md
Admissibility: charter/admissibility.md
Stability: governance/governance-and-stability.md

Final Note

Dust is a language for systems where meaning matters

If something is important, it must be explicit, constrained, and admissible. Nothing else is allowed to happen.