112 lines
3.5 KiB
Markdown
112 lines
3.5 KiB
Markdown
# PBS IR and Lowering Workshop 3
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the third focused discussion for `12. IR and Lowering Specification.md` on callable categories beyond ordinary top-level functions:
|
|
|
|
- callbacks,
|
|
- services,
|
|
- contracts,
|
|
- methods,
|
|
- and dispatch obligations.
|
|
|
|
## Why This Slice Third
|
|
|
|
This slice should come after control-flow lowering because it builds on the general execution model while introducing runtime-dispatch and identity-sensitive concerns.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm callable categories and identity facts already fixed.
|
|
2. Close callback formation and invocation lowering.
|
|
3. Close service and method lowering.
|
|
4. Close contract-view and dispatch lowering.
|
|
5. Record builtin and host-binding specifics for Workshop 4.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. The lowering story for callback formation and invocation.
|
|
2. The lowering story for service singleton methods.
|
|
3. The lowering story for contracts and dispatch.
|
|
4. Which runtime-artifact facts must be explicit versus implementation-defined.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Callback Lowering Must Preserve Captured Identity And Retention
|
|
|
|
Candidate direction:
|
|
|
|
- callback values created by `bind` lower to a representation that preserves:
|
|
target callable identity,
|
|
captured context identity,
|
|
and retention-bearing lifetime facts.
|
|
|
|
Rationale:
|
|
|
|
- These are already required by memory and semantics specs.
|
|
|
|
### 2. Service Lowering Preserves Singleton Identity
|
|
|
|
Candidate direction:
|
|
|
|
- service method calls lower through the module-owned singleton identity,
|
|
- and lowering must not accidentally materialize new service instances.
|
|
|
|
Rationale:
|
|
|
|
- This is a language-observable property.
|
|
|
|
### 3. Contract Lowering Must Preserve Selected Implementation Identity
|
|
|
|
Candidate direction:
|
|
|
|
- contract values lower as runtime-dispatchable views over an underlying owner plus implementation selection,
|
|
- but `12` does not freeze one concrete table or object layout yet.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the semantic contract clear while deferring layout choices.
|
|
|
|
### 4. Receiver-Bearing Method Calls Need Explicit Lowered Receiver Handling
|
|
|
|
Candidate direction:
|
|
|
|
- struct, service, and contract method calls lower through an explicit receiver-bearing callable shape,
|
|
- even if the backend later optimizes the representation.
|
|
|
|
Rationale:
|
|
|
|
- This keeps receiver identity and call semantics visible in the spec.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Does contract dispatch need a dedicated runtime artifact category in the spec?
|
|
2. Does callback lowering need one explicit abstract representation?
|
|
3. How much of method dispatch belongs in `12` versus runtime execution specs?
|
|
4. Are service methods lowered like receiver calls or like specialized global calls?
|
|
5. Which of these constructs need explicit artifact invariants before `15`?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record for callback lowering,
|
|
2. a decision record for service and contract lowering,
|
|
3. and callable-category section targets for `12`.
|
|
|
|
## Explicit Deferrals For Workshop 4
|
|
|
|
- builtin projection lowering,
|
|
- builtin constants,
|
|
- host-binding emission,
|
|
- and verifier-facing artifact invariants.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/4. Static Semantics Specification.md`
|
|
- `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.2. IR and Lowering Workshop 2 - Control Flow, Evaluation Order, and Propagation.md`
|
|
|