Module System

The Semantic module system resolves different artifact kinds through one shared boundary: source files, Semantic files, packages, native objects and binaries become canonical Semantic programs.

One universal import boundary

UniversalModuleResolver detects the artifact kind or accepts an explicit language. The result is a SemanticModule with UAST, origin, symbols, contracts and dependencies.

• .se Semantic source module
• .sp Semantic transport
• .spz canonical Semantic payload
• Go, Python, Rust, C/C++, C#, Java, Kotlin, Nim, Swift, Zig and other sources
• Assembly plus PE/COFF and other native artifacts

Auto-transpile import

“Auto-transpile” does not mean plain text translation. The internal frontend reads the source language and directly produces the shared Semantic representation.

Source or package  →  DetectArtifact / --language  →  LowerSource(...)  →  SemanticProgram + UniversalAST + Origin.Modules  →  SemanticModule  →  SPZ / SE / SMod

For Go, module paths are normalized from go.mod. Explicit external packages can be marked as pkg:go:.... The resolver checks the local Semantic store first and only uses local sources, archives or registry adapters on a cache miss.

SMod packages

.smod is a data-only package manifest, not a second AST format. It describes package identity and Semantic-ready units.

{ "name":"package", "module_path":"example.org/package", "package_hash":"...", "files":[{ "path":"src/file.go", "semantic_path":"semantic/src/file.go.spz", "readable_semantic_path":"semantic/src/file.go.se", "source_hash":"...", "symbols":["package.Function"], "status":"SEMANTIC_READY" }] }

The project linker can therefore load exactly the required units without scanning or transpiling the package again.

Cache model

Modules are stored content-addressably. The cache key binds the source hash, frontend/schema version, Semantic root, dependencies and contracts.

%LOCALAPPDATA%\Semantic\Modules  ·  index  ·  cache  ·  modules  ·  locks  ·  download  |  module.spz  ·  module.se  ·  module.meta

Embedding and linking

Dependencies are not blindly copied into every unit. The system supports inline (payload stored once), reference (owner reference) and external (deliberately unresolved external module).

Projects support references, needed and all. all materializes the complete declared module closure and is the relevant mode for a self-hosting full build.

Native modules

.obj, .exe and .dll files are analyzed with architecture and ABI facts. If lossless lifting is not possible, the artifact remains an explicit NATIVE_EXTERNAL module.

Why module identity matters for self-hosting

Native self-hosting is more than individual function bytes. Cross-unit calls, globals, layouts, symbol names and Semantic identities must agree.

Source / .se  →  internal frontends  →  Semantic units + SMod  →  project index  →  SemanticModulesAll  →  OBJ with symbols and relocations  →  Semantic linker → EXE / ELF

CLI

CodeTranspiler.exe semantic module import path/to/package  |  CodeTranspiler.exe semantic module import --language go path/to/main.go  |  CodeTranspiler.exe semantic module list  |  CodeTranspiler.exe semantic module verify <cache-key>  |  sp semantic module ...

Semantic package registry

The package registry is the public discovery and distribution layer for Semantic modules. Browse available packages through Modules or inspect the machine-readable modules.json index.

A package is identified by its module identity and manifest. The registry can expose source archives, Semantic-ready .se/.sp/.spz units, package hashes, dependencies, and official download URLs. Local module stores cache these packages so imports remain deterministic and can work offline after resolution.

SWC consumes this model through its module-specifier, module-store, resolver, and embedding units. The package registry is operational today; the remaining SWC work is to close every native compile-time resolver and embedding path around it.