Section 43: Compile-Time Evaluation and Constants¶
TECHSPEC-43 — Section 43 · Version 0.1 · Status: Initial Draft
Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.
1. Purpose¶
Compile-time evaluation permits selected expressions to be evaluated during compilation. It can improve safety and efficiency when the evaluated operations are deterministic and bounded.
Compile-time execution must not become an unrestricted second runtime.
2. Constants¶
CONST declares a value fixed at compile time.
Rules: - The initializer must be a permitted compile-time expression. - The resulting value is immutable. - The compiler must report the evaluated value and its source. - A constant cannot depend on runtime input, current time, random values, or external state.
3. Permitted Compile-Time Expressions¶
The initial permitted set should include: - Primitive literals. - Constant references. - Arithmetic with defined numeric semantics. - Boolean and comparison expressions. - Immutable aggregate construction. - Restricted pure functions explicitly eligible for compile-time evaluation.
The exact permitted set must be defined by the language specification.
4. Pure Compile-Time Functions¶
A compile-time function must: - Have no external effects. - Read no runtime state. - Use only permitted compile-time values. - Have deterministic semantics. - Operate within compiler resource limits. - Produce a value or an explicit compile-time error.
A PURE declaration is a claim to be checked, not proof by itself.
5. Resource Limits¶
Compile-time evaluation must have limits for: - Execution steps or fuel. - Memory allocation. - Recursion depth. - Output size. - Total compilation time attributable to evaluation.
Exceeding a limit must produce a diagnostic. The compiler must not silently substitute a guessed value.
6. Environment Independence¶
Compile-time results must not silently depend on: - Machine-specific paths. - Environment variables. - Current time. - Randomness. - Network responses. - Undeclared compiler configuration.
If target configuration affects a result, that configuration must be an explicit input and recorded in the build metadata.
7. Errors¶
Invalid constant expressions must fail compilation with a source-located diagnostic. Arithmetic errors follow the numeric semantics in Section 21.
8. Caching and Reproducibility¶
Cached results must be keyed by all relevant inputs, including compiler version, language version, target configuration, and source dependencies.
A cache hit is not independent evidence that the expression is correct.
9. Verification¶
The compiler records: - Expression source. - Evaluated value. - Compiler and language versions. - Relevant configuration. - Resource limits applied. - Any assumptions or unsupported properties.
10. MVP Scope¶
Support literal constants and simple deterministic expressions. Defer general compile-time functions until sandboxing, resource limits, and deterministic semantics are implemented.
11. Design Goal¶
Compile-time evaluation must be bounded, deterministic, inspectable, and incapable of silently reaching into the external world.
Source and related sections¶
Source file: TECHSPEC-43.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.