0x0 Language Specification

This specification is the public contract for the current implemented language

slice. It is intentionally narrower than a future language design document.

Source Model

A source file is a sequence of forms. Forms are parsed as atoms or lists.

Semantic validation then recognizes modules, imports, exports, functions,

annotations, bindings, conditionals, sequencing, calls, and literals.

Module Boundary

(⊙ name) declares the module name. If absent, compiler entry points default to

main.

The module name controls emitted OISA module identity. Imported files do not

replace the root module name.

Imports

↥ imports another .0x0 source file before compiling the importing file.

Relative imports resolve from the importing file's directory. pkg: imports

resolve through 0x0.lock.

Aliases expose imported functions as alias.name.

Functions

Functions use ƒ, optional annotations, a parameter list, and body forms. Body

forms are evaluated in order. The final body expression is the return value. An

empty body returns Unit.

Annotations

Current annotations:

• ∷: checked source type contract for the implemented type slice;
• doc: source documentation used by API docs and skipped by emitters;
• cap: capability contract for pure/effectful boundaries.

Emitters skip annotations after validation.

Evaluation

The current language supports direct calls, builtin calls, local bindings,

conditionals, sequencing, and values documented in docs/language.html.

The current truth rule treats nil and false as false in the C compatibility

runtime. The ELF slice uses the value register for branch tests in supported

examples and compiler paths.

Semantic Validation

The compiler validates:

• top-level form shape;
• module and function name shape;
• duplicate function names;
• duplicate parameters;
• local symbol resolution;
• call head shape;
• user function existence and arity;
• builtin arity;
• simple concrete type mismatches for I64, Text, Bool, and Unit;
• if condition type when inferable;
• equality operand compatibility when inferable;
• pure capability boundaries.

Type System Status

The current checker is not a complete type system. It deliberately treats

unresolved complex cases as Any instead of pretending to prove them.

Capability Status

Source capability names are pure, io, file, network, and process.

network and process can describe framework/runtime boundaries, but current

core language builtins do not expose generic sockets or subprocess execution as

ordinary builtins.

Backend Status

Backend support is artifact-specific. OISA, C compatibility, native executable,

object, archive, linker, and direct ELF paths have documented slices and should

not be described as identical coverage unless a gate proves it.