Topaz treats a program as an executable statement of intent, readable enough for review and precise enough for execution. The goal is not to maximize syntax, but to make ordinary programs direct and consistent.
One clear form
Ordinary code should have one preferred form. Domain names can remain in Unicode, effects and failures stay visible, and unready features remain out of examples. This keeps human-written code and generated code equally readable.
Predictable execution
When a selected target supports a program, the same source should preserve its visible behavior whether run directly, compiled to a native binary, or emitted as Python. The current SPEC defines values, ordering, errors, and cleanup while leaving implementations free to choose their internal representations. A target that cannot preserve required behavior must reject the program explicitly.
Multiple useful outputs
Rust, Python, and Web targets address distinct deployment requirements without creating separate Topaz dialects. A program is checked once, then routed to a supported output path. Unsupported constructs are rejected rather than assigned target-specific meanings. Behavioral differences between paths accepting the same source are treated as compiler bugs rather than language choices.
Coherent grammar, explicit semantics
A focused grammar and standard library provide readers, tools, and implementations with the same target. Topaz can grow, but new features should arrive with defined behavior, working implementations, examples, and documentation.
Real programs guide growth
Maintained applications reveal real library and runtime demand across strings, numbers, collections, files, packages, and diagnostics. The Lispex test and integration surface exercises recursion, portable values, state management, printing, and error handling in end-to-end workflows. Production evidence guides implementation and language priorities without accumulating one-off syntax.
Current product status
The documentation presents current-release capabilities, target-specific behavior, and planned additions in their relevant contexts, while internal development procedures remain in engineering records rather than public language rules.