3.5 KiB
PBS Lowering IRBackend Specification
Status: Draft v1 (Frontend Scope)
Applies to: first lowering boundary from bound PBS frontend model into IRBackend/IRBackendFile
1. Purpose
This document defines the normative frontend lowering contract from PBS source semantics to IRBackend.
Its purpose is to keep the first lowering deterministic and shared across implementations while PBS and backend design evolve.
2. Scope
This document defines:
- required preconditions before lowering starts,
- semantic obligations preserved in
IRBackend, - deterministic rejection behavior for unsupported frontend-lowering forms,
- and diagnostics attribution obligations for lowering failures in frontend scope.
This document does not define:
- VM lowering (
IRVM), - bytecode/PBX mapping,
- runtime execution behavior,
- verifier/loader internals.
Those concerns belong to shared acceptance specs under docs/general/specs.
3. Authority and Precedence
Normative precedence:
3. Core Syntax Specification.md4. Static Semantics Specification.md11. AST Specification.md12. Diagnostics Specification.md- This document
If a lowering rule here conflicts with higher-precedence syntax/semantics rules, the higher-precedence rule wins.
4. Normative Inputs
This document depends on:
3. Core Syntax Specification.md4. Static Semantics Specification.md11. AST Specification.md12. Diagnostics Specification.md
5. Lowering Preconditions
Frontend lowering into IRBackend may start only when:
- source has been tokenized and parsed,
- required syntax diagnostics have been emitted,
- linking/name-resolution outcomes required for the current lowering slice are available,
- and no unresolved semantic ambiguity is deferred to lowering.
Lowering must not invent unresolved semantic answers that belong to syntax/static/linking phases.
6. IRBackend Preserved Obligations
For each callable admitted by the current lowering slice, IRBackend must preserve at minimum:
- callable identity (name/category as applicable),
- callable arity,
- declared return surface information,
- source attribution anchor (
file + span) for diagnostics and traceability.
The normative contract is obligation-based, not tied to one mandatory in-memory class graph.
7. Deterministic Rejection Policy
If a source form is outside current frontend-lowering support:
- rejection must be deterministic,
- diagnostics must expose stable
code,severity, and primary attribution, - and unsupported forms must not silently degrade into different valid lowered behavior.
8. Conformance Boundary
IRBackend is the first lowering boundary (frontend responsibility).
Conformance-valid claims at this boundary require evidence from docs/general/specs/13. Conformance Test Specification.md and must only be published when the full claimed PBS surface is implemented at IRBackend level.
9. Explicit Deferrals
The following are intentionally out of scope for this document:
IRBackend -> IRVMlowering,- artifact encoding and binary layout,
- runtime lifecycle behavior,
- verifier and loader checks.
10. Non-Goals
- Freezing one optimizer strategy.
- Freezing one compiler architecture.
- Repeating runtime or bytecode authority.
11. Exit Criteria
This document is healthy when:
- lowering preconditions are explicit,
- preserved
IRBackendobligations are explicit, - deterministic rejection policy is explicit and test-backed,
- and scope boundaries with general/backend acceptance specs are explicit.