118 lines
3.4 KiB
Markdown
118 lines
3.4 KiB
Markdown
# PBS IR and Lowering Workshop 2
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the second focused discussion for `12. IR and Lowering Specification.md` on control flow and propagation:
|
|
|
|
- evaluation order,
|
|
- branching,
|
|
- abrupt completion,
|
|
- `optional`,
|
|
- `result`,
|
|
- `!`,
|
|
- and `handle`.
|
|
|
|
## Why This Slice Second
|
|
|
|
This slice follows naturally from Workshop 1 because it applies the preserved-obligations model to the core execution constructs.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm the preserved semantic obligations from Workshop 1.
|
|
2. Close evaluation-order preservation in lowered form.
|
|
3. Close the lowered model for branching and abrupt completion.
|
|
4. Close the lowered model for `optional` and `result` propagation.
|
|
5. Record callable and runtime-artifact issues for Workshop 3.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. How evaluation order is preserved explicitly.
|
|
2. How abrupt completion is represented in lowered control flow.
|
|
3. The lowered shape of `optional else`, `expr!`, and `handle`.
|
|
4. The boundary between propagation and trap in lowering.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Lowering Must Make Single Evaluation Explicit
|
|
|
|
Candidate direction:
|
|
|
|
- call target formation,
|
|
- argument evaluation,
|
|
- `if` conditions,
|
|
- `switch` selectors,
|
|
- `some(expr)` payload formation,
|
|
- and `bind(context, fn_name)` capture
|
|
must each lower to explicit once-only evaluation points.
|
|
|
|
Rationale:
|
|
|
|
- These are already language-observable guarantees.
|
|
|
|
### 2. Branching Lowers To Explicit Control Transfers
|
|
|
|
Candidate direction:
|
|
|
|
- `if` and `switch` lower to explicit branch structure,
|
|
- non-selected arms do not evaluate,
|
|
- and tail-result formation is explicit rather than implicit.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the dynamic-semantics contract visible through lowering.
|
|
|
|
### 3. Propagation Uses Dedicated Lowered Paths
|
|
|
|
Candidate direction:
|
|
|
|
- `optional else` lowers to a presence test plus fallback path,
|
|
- `expr!` lowers to success-path unpack plus immediate error propagation path,
|
|
- `handle` lowers to explicit arm dispatch over the error case space.
|
|
|
|
Rationale:
|
|
|
|
- These constructs are semantically distinct enough that ordinary expression lowering should not blur them.
|
|
|
|
### 4. Trap Is Not Rewritten Into Result Flow
|
|
|
|
Candidate direction:
|
|
|
|
- lowered trap paths remain fatal abort paths outside ordinary `result` propagation,
|
|
- and `handle` never intercepts trap.
|
|
|
|
Rationale:
|
|
|
|
- This preserves the existing semantics cleanly.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Does `12` need dedicated abstract operations for propagation, or only obligations on the emitted control flow?
|
|
2. How explicit must once-only evaluation be in the spec text?
|
|
3. Does `switch` lowering need one canonical decision-tree shape?
|
|
4. Is `handle` best specified as arm dispatch plus remap semantics, or as a more abstract effect-preservation rule?
|
|
5. Which of these details belong to `12` versus `15`?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record for evaluation-order preservation,
|
|
2. a decision record for propagation lowering,
|
|
3. and control-flow section targets for `12`.
|
|
|
|
## Explicit Deferrals For Workshop 3
|
|
|
|
- services,
|
|
- contracts,
|
|
- callbacks,
|
|
- and runtime dispatch artifacts.
|
|
|
|
## 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/agendas/12. IR and Lowering Agenda.md`
|
|
- `docs/pbs/agendas/12.1. IR and Lowering Workshop 1 - Lowering Contract and IR Status.md`
|
|
|