04 — Token System
Token Aliasing
Aliasing allows a token to reference another token of the same tier as its value. An alias chain consists of one or more alias references that ultimately resolve to a concrete value. Alias chains MUST resolve to a concrete value within three hops. Circular aliases — where a token directly or transitively references itself — are a Transform-phase error. Aliasing across tiers is prohibited.
Alias Resolution
The compiler resolves alias chains during Transform. Full resolution means that every token in the system has a concrete value after Transform — no alias reference persists into the Emit phase. Emitters receive resolved values, not alias chains. This ensures that platform emitters do not need to implement alias resolution logic and that emitter output is deterministic.
Maximum Alias Chain Length
| Chain Length | Status | Notes |
|---|---|---|
| 1 hop | Valid | Token A → Token B (concrete value) |
| 2 hops | Valid | Token A → Token B → Token C (concrete value) |
| 3 hops | Valid | Maximum permitted depth |
| 4+ hops | Transform error | Indicates token architecture that should be refactored |
| Circular | Transform error | Detected at any depth |
When to Use Aliasing
Aliasing is appropriate when a semantic token should adopt the value of another semantic token in a specific context — for example, when a component's hover state background should match the system's active state background. It is not a mechanism for creating token shortcuts or abbreviations. Excessive aliasing depth is an indicator of token architecture problems that should be resolved by restructuring the token set.