Section 57: Open Questions and Unresolved Design Decisions¶
TECHSPEC-57 — Section 57 · Version 0.1 · Status: Working Register
Working register: this section is the authoritative register of open design decisions (OQ-001 – OQ-029). Also see Unresolved Questions.
Status: Working Register. Open decisions recorded here must not be treated as settled.
1. Purpose¶
This section records decisions that remain open across the Technical Specification.
An unresolved decision must not be treated as settled merely because an example uses one possible syntax or behavior.
The register should be updated whenever a decision is made. Each decision should include its status, rationale, affected sections, and consequences.
2. Core Language Decisions¶
| ID | Decision | Current Status |
|---|---|---|
| OQ-001 | Final source grammar and declaration terminators | Open |
| OQ-002 | Exact numeric representation and Decimal conformance target | Open |
| OQ-003 | Integer division and remainder semantics | Open |
| OQ-004 | Decimal rounding context and inexact-result reporting | Open |
| OQ-005 | String indexing and grapheme-aware operations | Open |
| OQ-006 | Map iteration order guarantees | Open |
| OQ-007 | Exact syntax for references, ownership, and borrowing | Open |
| OQ-008 | Generic variance rules | Open |
| OQ-009 | Interface and trait coherence rules | Open |
| OQ-010 | Exact contract refinement rules for behavioral subtyping | Open |
3. Runtime and Execution Decisions¶
| ID | Decision | Current Status |
|---|---|---|
| OQ-011 | Runtime architecture and Python execution strategy | Open |
| OQ-012 | Exact task scheduling and cancellation semantics | Open |
| OQ-013 | Memory allocation failure representation | Open |
| OQ-014 | Garbage collection strategy and configuration | Open |
| OQ-015 | Resource-budget syntax and enforcement model | Open |
| OQ-016 | Runtime isolation profiles and platform guarantees | Open |
| OQ-017 | Deterministic execution guarantees across targets | Open |
4. Verification Decisions¶
| ID | Decision | Current Status |
|---|---|---|
| OQ-018 | Formal proof language and proof engine | Open |
| OQ-019 | Supported proof obligations in the first compiler | Open |
| OQ-020 | Evidence record schema and report format | Open |
| OQ-021 | Rules for invalidating evidence after code changes | Open |
| OQ-022 | Independent verifier architecture | Open |
| OQ-023 | Exact meaning and release requirements for VERIFIED |
Open |
5. Ecosystem Decisions¶
| ID | Decision | Current Status |
|---|---|---|
| OQ-024 | Package registry and publisher identity model | Open |
| OQ-025 | Standard library release and compatibility policy | Open |
| OQ-026 | FFI support and unsafe boundary syntax | Open |
| OQ-027 | Macro and metaprogramming model | Deferred |
| OQ-028 | Runtime reflection and dynamic loading scope | Deferred |
| OQ-029 | Native and WebAssembly compilation targets | Deferred |
6. Decision Process¶
Each decision should be resolved through the following record:
- Problem: What exact ambiguity or requirement needs a decision?
- Options: What viable alternatives exist?
- Consequences: What does each option mean for safety, usability, implementation, and compatibility?
- Selection: Which option is chosen?
- Rationale: Why was it selected?
- Evidence: What supports the decision?
- Affected sections: Which specification sections must change?
- Status: Open, Proposed, Accepted, Rejected, or Deferred.
7. No Silent Resolution¶
Implementation convenience must not silently settle a language-level question.
If the compiler requires a behavior that the specification has not defined, the behavior must be recorded as provisional and must not be presented as a stable language guarantee.
8. Completion Criteria¶
The Technical Specification may be considered ready for implementation planning when: - Every core language behavior has a defined rule. - Conflicting or ambiguous rules have been resolved. - MVP features and deferred features are clearly separated. - Verification claims have precise meanings. - Runtime and target assumptions are documented. - Open questions that affect MVP correctness have been resolved or explicitly bounded.
9. Design Goal¶
The specification must make uncertainty visible. An explicit open question is safer than an accidental design decision hidden in code.
Source and related sections¶
Source file: TECHSPEC-57.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.