87 lines
3.0 KiB
Markdown
87 lines
3.0 KiB
Markdown
# PBS Frontend IR and Lowering Workshop 2
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the second focused discussion for `13. Lowering IRBackend Specification.md` on frontend-lowering obligations for:
|
|
|
|
- expression evaluation order,
|
|
- branching behavior,
|
|
- and propagation-related constructs at frontend IR boundary.
|
|
|
|
## Why This Slice Second
|
|
|
|
After Workshop 1 closes contract/preconditions, this workshop closes construct-level obligations that must be testable in frontend scope.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm preserved obligations from Workshop 1.
|
|
2. Close once-only evaluation obligations in frontend IR terms.
|
|
3. Close branch and abrupt-completion representation obligations.
|
|
4. Close propagation construct obligations (`optional`, `result`, `!`, `handle`) at frontend boundary.
|
|
5. Record callable-category leftovers for Workshop 3.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. Which evaluation-order guarantees must remain explicit in frontend IR obligations.
|
|
2. Which branch/abrupt-completion facts are mandatory in v1 frontend lowering.
|
|
3. Which propagation constructs are in-scope versus deterministic rejection in v1 slice.
|
|
4. Which diagnostics are required when unsupported propagation constructs are used.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Frontend Lowering Must Preserve Once-Only Evaluation Facts
|
|
|
|
Candidate direction:
|
|
|
|
- source-observable single-evaluation points are preserved as explicit lowering obligations,
|
|
- independent of one exact IR node taxonomy.
|
|
|
|
### 2. Branching Obligations Are Normative At Frontend Boundary
|
|
|
|
Candidate direction:
|
|
|
|
- selected/non-selected branch semantics remain explicit in frontend lowering contract,
|
|
- with no implicit permissive fallbacks.
|
|
|
|
### 3. Propagation Constructs Have Explicit V1 Status
|
|
|
|
Candidate direction:
|
|
|
|
- each construct is marked `supported in v1 frontend lowering` or `deterministic reject`,
|
|
- and this status is mirrored in Gate U fixtures.
|
|
|
|
### 4. Diagnostics Identity Must Be Stable For Unsupported Forms
|
|
|
|
Candidate direction:
|
|
|
|
- unsupported forms emit stable code/severity/primary attribution,
|
|
- so regression tests can lock behavior.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Which propagation constructs are fully represented now versus deferred?
|
|
2. What minimum frontend IR evidence is enough to prove evaluation-order obligations?
|
|
3. Which failures should be classified as parse/static errors versus lowering errors?
|
|
4. Which fixture shapes are mandatory for Gate U here?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision note on expression/control-flow lowering obligations,
|
|
2. a decision note on propagation status map (support/reject),
|
|
3. and fixture targets for frontend conformance tests.
|
|
|
|
## Explicit Deferrals For Workshop 3
|
|
|
|
- callable-category representation details,
|
|
- and service/contract/callback-specific obligations.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
|
|
- `docs/pbs/specs/12. Diagnostics Specification.md`
|
|
- `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
|
- `docs/general/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/agendas/archive/13.1. IR and Lowering Workshop 1 - Lowering Contract and IR Status.md`
|