Section 56: Language Conformance and Compatibility Requirements¶

TECHSPEC-56 — Section 56 · 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¶

Conformance defines what it means for a compiler or runtime to implement the language specification.

Compatibility defines which programs and artifacts remain valid across language, compiler, runtime, and library versions.

2. Conformance¶

A conforming implementation must satisfy: - Lexical and grammar requirements. - Type-system rules. - Expression and evaluation semantics. - Function and contract semantics. - Ownership and mutability rules. - Error and failure behavior. - Effect and permission rules. - Runtime behavior required by the specification. - Verification-report requirements.

Unsupported features must be rejected or clearly identified as unsupported. They must not be silently interpreted with different semantics.

3. Conformance Test Suite¶

The project must maintain: - Positive tests for valid programs. - Negative tests for invalid programs. - Runtime semantic tests. - Contract and failure tests. - Cross-target behavior tests. - Diagnostic conformance tests. - Verification-report schema tests. - Regression tests for confirmed defects.

The suite itself requires review and integrity protection. Passing it is evidence of conformance, not a proof that every possible program is handled correctly.

4. Implementation Profiles¶

The specification may define profiles for implementations with different capabilities.

A profile must list: - Supported language features. - Unsupported features. - Runtime requirements. - Verification capabilities. - Platform restrictions. - Known limitations.

An implementation must not claim a stronger profile than its tests and evidence support.

5. Compatibility Categories¶

Compatibility must be considered separately for: - Source syntax. - Type semantics. - Runtime semantics. - Binary interfaces. - Public module interfaces. - Contracts and effects. - Standard library APIs. - Package formats. - Verification reports.

A source-compatible change may still alter runtime behavior or invalidate prior verification evidence.

6. Version Compatibility¶

Language, compiler, runtime, standard library, and package versions must be recorded separately.

Compatibility claims must identify the exact versions and supported combinations.

7. Deprecation and Breaking Changes¶

Breaking changes require: - A documented reason. - Migration guidance. - Compatibility impact analysis. - Updated conformance tests. - A defined transition period where practical.

Automated migration tools must show their changes and must not claim that migrated behavior is equivalent without evidence.

8. Cross-Implementation Consistency¶

Independent compiler implementations must produce behavior consistent with the language specification.

Differences caused by target platforms must be explicitly permitted and documented by the specification.

9. Design Goal¶

A program's meaning must come from the language specification, not from accidental differences between compiler implementations.

Source file: TECHSPEC-56.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.