Design Principles¶

Catalyst is a general-purpose native language for predictable high performance. It should make low-level behavior visible without turning the language into a ceremony-heavy proof system.

Core Philosophy¶

The compiler is an instrument panel, not a cop.

The compiler should expose consequences, costs, diagnostics, and likely mistakes. It should not hide runtime behavior, fight the programmer by default, or require pervasive ownership bureaucracy before code can be expressed.

Design Criteria¶

Catalyst language design should be judged against these criteria:

• Readability: code should be easy to read and understand accurately.
• Writeability: code should be clear, idiomatic, concise, and quick to write without sacrificing clarity.
• Expressivity: the language should support a wide variety of programs without becoming a narrow DSL.
• Reliability: the language should minimize undefined behavior and make unsafe, unchecked, or implementation-defined behavior explicit.
• Orthogonality: a small set of primitive constructs should combine predictably with few special cases.
• Uniformity: similar features should look and behave similarly.
• Maintainability: errors should be easy to find and correct, and features should be easy to evolve.
• Generality: closely related constructs should be unified where doing so reduces special cases.
• Extensibility: users should have principled mechanisms to build new abstractions.
• Portability: programs should be transportable across targets without unnecessary language-level changes.
• Implementability: the language should remain practical to parse, compile, interpret, and optimize.
• Safety: mechanisms should exist to detect errors before they become runtime failures.
• Efficiency: language features should not preclude efficient native code generation.
• Modularity: parts of a program should be understandable and eventually compilable in isolation.

When criteria conflict, clarity has priority over compactness.

No Hidden Runtime Behavior¶

Catalyst should avoid hidden:

• allocation
• virtual dispatch
• async runtimes
• global state
• IO
• locks
• blocking behavior

Important runtime effects should be visible through function signatures, explicit context values, explicit types, or explicit APIs.

Trust the Programmer¶

Trust the programmer. Give them sharp tools, but help them not cut themselves. When a powerful feature is coherent, inspectable, and diagnosable, the default design bias is to expose it with clear boundaries rather than forbid it preemptively.

Catalyst rejects pervasive lifetime and borrow proofs as a core language identity. That does not mean unsafe chaos. It means the language should prefer explicit APIs, strong diagnostics, compiler-integrated linting, and clear conventions over restrictive proof machinery.

Simplicity Over Cleverness¶

The language should prefer small orthogonal concepts, predictable semantics, low punctuation noise, and one primary abstraction mechanism. It should avoid mini languages inside the type system or macro system.

Complex metaprogramming belongs in deterministic comptime, not in recursive type algebra or a separate macro language.

Tooling Is a Design Constraint¶

Comptime-heavy code must remain understandable by tooling. Autocomplete, inferred types, generated declarations, and structural constraints should remain queryable by IDE and compiler tooling.

If a language feature is powerful but makes semantic information opaque, it is suspect.

Performance Is Inspectable¶

High-performance code should be inspectable through deterministic dumps, explicit IR facts, and readable generated C in the first backend. Optimization is important, but the first milestone prioritizes phase clarity, verifiability, and generated-output determinism.