117 lines
3.6 KiB
Markdown
117 lines
3.6 KiB
Markdown
# PBS IR and Lowering Workshop 1
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the first focused discussion for `12. IR and Lowering Specification.md` on the front door of lowering:
|
|
|
|
- what the lowering contract consumes,
|
|
- whether IR itself is normative,
|
|
- and which semantic obligations must be preserved independent of IR shape.
|
|
|
|
## Why This Slice First
|
|
|
|
This slice should come first because every later lowering discussion depends on knowing:
|
|
|
|
- what counts as a well-formed input to lowering,
|
|
- and whether the spec standardizes one IR shape or only semantic preservation duties.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm already-settled lowering inputs.
|
|
2. Close the preconditions for lowering.
|
|
3. Close the normative status of IR.
|
|
4. Close the minimum preserved semantic obligations.
|
|
5. Record construct-specific issues for later workshops.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. The normative status of IR in PBS v1.
|
|
2. The minimum required input state before lowering begins.
|
|
3. The semantic facts that lowering must preserve regardless of IR architecture.
|
|
4. The boundary between `12` and `15`.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Standardize Preserved Obligations, Not One Canonical In-Memory IR
|
|
|
|
Candidate direction:
|
|
|
|
- PBS v1 does not require one canonical compiler IR data model,
|
|
- but it does require one stable set of preserved semantic obligations.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the spec implementation-neutral while still preventing semantic drift.
|
|
|
|
Alternative to discuss:
|
|
|
|
- define one normative abstract IR grammar in the spec.
|
|
|
|
### 2. Lowering Preconditions Require A Fully Bound Program
|
|
|
|
Candidate direction:
|
|
|
|
- parsing, name resolution, visibility/linking, and type checking must already be complete,
|
|
- reserved builtin and host metadata must already be validated,
|
|
- callable sets and canonical identities must already be resolved.
|
|
|
|
Rationale:
|
|
|
|
- Lowering should not invent unresolved semantic answers.
|
|
|
|
### 3. Minimum Preserved Obligations Include Evaluation Order, Identity, and Host Boundary Facts
|
|
|
|
Candidate direction:
|
|
|
|
- lowering must preserve:
|
|
source-observable evaluation order,
|
|
abrupt-completion behavior,
|
|
value-identity and aliasing facts,
|
|
host-boundary crossings,
|
|
and trap-versus-propagation distinctions.
|
|
|
|
Rationale:
|
|
|
|
- These are the semantic anchors later workshops will rely on.
|
|
|
|
### 4. `15` Owns Final Artifact Layout, `12` Owns The Contract Before It
|
|
|
|
Candidate direction:
|
|
|
|
- `12` defines the semantic and artifact-facing invariants a lowered program must satisfy,
|
|
- `15` defines the final PBX and bytecode mapping details.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the lowering spec from collapsing into artifact byte layout.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Is obligations-only precise enough, or does PBS need a normative abstract IR?
|
|
2. Should canonical identity resolution be fully complete before lowering?
|
|
3. Which semantic facts are mandatory to preserve explicitly rather than infer later?
|
|
4. Does `12` need one explicit “bound program” model?
|
|
5. How much artifact vocabulary can `12` use before it starts stealing `15`'s job?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record on IR status,
|
|
2. a decision record on lowering preconditions,
|
|
3. and a checklist of preserved semantic obligations for `12`.
|
|
|
|
## Explicit Deferrals For Workshop 2
|
|
|
|
- control-flow shapes,
|
|
- propagation operators,
|
|
- and callable-category-specific lowering.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
|
|
- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
|
|
- `docs/pbs/specs/12. IR and Lowering Specification.md`
|
|
- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
- `docs/pbs/agendas/12. IR and Lowering Agenda.md`
|