Composition Model

Composition in IDL is explicit and unambiguous. No relationship between components, tokens, or modules may be inferred — every dependency is declared. The composition model governs three distinct composition concerns: token composition (how tokens reference other tokens), slot composition (how components accept child components), and module composition (how modules import declarations from other modules).

Token Composition

Token composition follows the three-tier hierarchy: Primitive → Semantic → Component. A token may reference another token of the same tier or a tier beneath it. Forward references (a Primitive referencing a Semantic) and cross-tier aliasing (a Component token directly referencing a Primitive) are both Transform errors. The compiler resolves the full reference chain and validates it during Transform.

Slot Composition

Slot composition governs how components accept other components as typed content. A slot declaration specifies the accepted component type. A component may only be placed in a slot whose declared type it satisfies. The compiler builds the full slot graph from component declarations and validates that the graph is acyclic. A component that directly or transitively contains itself via slot references is a Transform error.

Module Composition

Module composition governs how IDL source files reference declarations from other files. Imports are explicit and unidirectional. The compiler detects circular imports at Parse time. A module may re-export declarations from imported modules; re-exports are tracked in the AST and included in dependency graph analysis. Module composition rules apply equally to all declaration types — tokens, components, constraints, and patterns.