# 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`