prometeu-studio/docs/pbs/agendas/12.2. IR and Lowering Workshop 2 - Control Flow, Evaluation Order, and Propagation.md

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