Speak in meaning. Think beyond syntax. Built beyond language.

Project Status

This page is intentionally conservative. It records engineering state, not a release promise.

What works today

  • Semantic compiler units can be parsed/indexed independently.
  • Multiple units can compile in parallel worker processes.
  • Successful Windows x86-64 COFF .obj artifacts are persisted even when other units fail.
  • Native backend diagnostics identify missing resolver/layout/control-flow capabilities explicitly.
  • The compiler graph is large enough to exercise real cross-unit selfhosting problems rather than a toy subset.

What is still incomplete

  • not every compiler unit lowers successfully yet;
  • some bindings/selectors still lose enough source/type context to fail native lowering;
  • some advanced control-flow/transport forms still need general backend support;
  • final project linking has not yet produced a fully verified Stage 2 selfhost compiler from the complete compiler source;
  • Stage 2 → Stage 3 bootstrap equivalence is therefore not yet proven.

SWC Windows compiler status

The Semantic Windows Compiler (SWC) is the native Windows x64 compiler track. It is separate from the minimal Linux MSPLC selfhosting milestone. The current SWC package contains swc.exe, the canonical Semantic compiler source, reader units, UAST units, transpiler-matrix data, module/lowering contracts, tests, and tools.

Available now

  • swc version and swc help are native CLI paths.
  • swc compile accepts the current Semantic transport forms .se, .sp, .spz, .json, and .smod.
  • Compile mode flags are defined for --embed-all, --embed-needed, and --no-modules.
  • The source tree contains the Semantic reader pipeline, format dispatch, current UAST subset, matrix data, module seams, and PE-target contracts.

Not yet proven

  • The former Go transpiler is not yet fully replaced by a native SWC transpiler.
  • The complete rich-UAST lowering closure is not yet implemented.
  • Complete PE machine-code emission and executable linking are not yet closed.
  • Compiling a large rich Semantic source can currently return exit code 0 while producing a small fallback PE stub. That is an emitter limitation, not a successful compiler build.
  • Full Windows SWC selfhosting is not claimed until a functional Stage 2 compiler recompiles the same source and Stage 3 verification passes.

For status interpretation, distinguish a source unit, a contract, a route, a generated object, a linked PE file, a runnable executable, and a selfhosting stage. They are separate evidence levels and must not be collapsed into one “working” label.

AI-assisted development: Semantic for AI, built with AI

Semantic is being developed with AI systems as engineering partners and is designed so that future AI systems can read and transform programs through explicit meaning. Human developers define the intended semantics, constraints, repository boundaries, and acceptance tests. AI agents inspect Semantic entities and relations, split work into small .se units, use the transpiler matrix and compiler evidence, run focused probes, and report exactly which proof level was reached.

This is “AI for AI” in two connected senses: AI helps build the language, compiler, documentation, and tests; and the resulting Semantic representation is structured so another AI can understand bindings, scopes, types, control flow, data flow, evaluation order, effects, contracts, ABI requirements, and lowering evidence without reconstructing everything from surface syntax.

Rules for AI-readable status

  1. Meaning comes before syntax. A source spelling is not a semantic guarantee.
  2. Known facts, implementation seams, probes, and unverified assumptions are recorded separately.
  3. Unknown UAST nodes or relations are rejected or marked explicitly; they are not silently invented.
  4. A successful command exit code is not proof of a functional output executable.
  5. Every major implementation step should be followed by focused tests and, where relevant, a selfhosting check.

Development loop

flowchart LR H[Human intent and acceptance criteria] --> C[Semantic contract] C --> U[Small .se unit] U --> T[Focused test or probe] T --> E[Object, PE, runtime, or selfhost evidence] E --> R[Human and AI review] R -->|proven| N[Next unit] R -->|not proven| C

The project therefore treats AI output as reviewable engineering evidence, not as an authority. The desired end state is a compiler and program representation that humans can audit, machines can execute, and AI systems can reason about without silently losing semantic information.

Development snapshots

Object counts are debugging metrics, not language-version guarantees. Historical runs have shown steady progress as common resolver and lowering families were implemented.

One stable uploaded run reported:

total=95
ready=16
timeout=1
failed=78
objects=54

Subsequent development runs increased the number of successful units and object artifacts. The correct long-term success criterion is not the object count itself, but completion of the full selfhosting chain.

Milestones

  • real .se compiler graph available
  • isolated project/unit build mode
  • parallel workers with hard process timeout
  • persist successful COFF objects
  • grouped resolver/layout debugging
  • every required compiler unit native-lowers successfully
  • project link produces Stage 2 compiler
  • Stage 2 recompiles the same compiler source
  • Stage 3 verification passes

Package registry and modules

The Semantic package registry is a working part of the ecosystem. It provides a public discovery and distribution layer for Semantic modules, package metadata, manifests, source archives, Semantic-ready files, and official module links. The registry index is published as modules.json and browsable through the Semantic Modules page.

Module identity, source hashes, dependencies, local stores, registry lookup, and package manifests give SWC and future Semantic tools a stable boundary for importing packages. SWC is progressively connecting this registry layer to native compile-time dependency resolution and embedding policies.

Selfhosting foundation

Selfhosting is a central project achievement, not merely a future idea. The current compiler source has a reproducible Stage 2 → Stage 3 proof for the supported selfhost closure, while the minimal Linux MSPLC track provides the independent Stage 1 → Stage 2 → Stage 3 milestone. The remaining work is to extend that proven foundation across the complete rich UAST and Windows PE backend.