# PBS Frontend IR and Lowering Workshop 1

Status: Closed (2026-03-05)

## Purpose

Run the first focused discussion for `13. Lowering IRBackend Specification.md` in frontend scope:

- what frontend lowering consumes,
- what frontend lowering must produce,
- and whether one canonical frontend IR shape is required.

## Why This Slice First

Every later workshop depends on a stable contract for:

- preconditions before lowering,
- and which frontend IR obligations are normative.

## Proposed Meeting Order

1. Reconfirm frontend-only scope boundary for agenda 13.
2. Close minimum preconditions before frontend lowering starts.
3. Close normative status of frontend IR shape versus obligations.
4. Close minimum preserved semantic facts for v1.
5. Record construct-specific gaps for Workshops 2 to 4.

## Decisions To Produce

1. Normative status of frontend IR in v1.
2. Required input state before frontend lowering begins.
3. Minimum preserved semantic facts at frontend-lowering boundary.
4. Minimum deterministic rejection policy for unsupported lowering inputs.

## Candidate Decisions

### 1. Standardize Preserved Obligations, Not One In-Memory Class Graph

Candidate direction:

- v1 standardizes preserved frontend obligations and observable outcomes,
- not one mandatory Java object model.

### 2. Frontend Lowering Requires Fully Parsed and Linked Source

Candidate direction:

- parser and linking outcomes are already complete,
- type/name diagnostics already produced where required,
- and lowering does not invent unresolved semantic answers.

### 3. Minimum Preserved Facts For V1 Frontend IR

Candidate direction:

- callable identity,
- parameter arity,
- declared return surface,
- and source attribution anchor (`file + span`) for diagnostics.

### 4. Unsupported Constructs Must Fail Deterministically

Candidate direction:

- constructs outside v1 frontend-lowering slice fail with stable diagnostics,
- never silently degrade into partial/implicit behavior.

## Questions To Resolve In The Room

1. Which facts are mandatory in v1 `IRFunction` versus optional?
2. Is obligations-only precise enough for conformance tests?
3. Which rejected constructs must already have fixed diagnostic codes?
4. What is the exact pass/fail boundary between parser/linking and frontend lowering errors?

## Expected Outputs

1. a decision note on frontend IR normative status,
2. a decision note on lowering preconditions,
3. and a checklist of preserved frontend-lowering obligations.

## Decision Outcome (2026-03-05)

1. `13` remains normative by preserved obligations, not by one mandatory in-memory IR shape.
2. Frontend lowering starts only after parse/linking completion and required prior diagnostics.
3. Minimum v1 frontend IR facts are mandatory: callable identity, arity, declared return surface, and source anchor (`file + span`).
4. Unsupported frontend-lowering forms must fail deterministically with stable diagnostics.
5. Scope boundary confirmed: `IRBackend` is the first lowering (frontend responsibility); `IRVM` is a later lowering (backend responsibility) and is out of `13` agenda scope.
6. Evidence baseline confirmed for now: Gate U only (`lexer/parser/AST/IRBackend/diagnostics`), without S-U requirement at this stage.
7. Conformance-valid IR claim rule: only when the full PBS spec surface is implemented at `IRBackend` level.

## Explicit Deferrals For Workshop 2

- expression/control-flow construct mapping details,
- and propagation construct obligations.

## Inputs

- `docs/pbs/specs/4. Static Semantics Specification.md`
- `docs/pbs/specs/12. Diagnostics Specification.md`
- `docs/pbs/specs/13. Lowering IRBackend Specification.md`
- `docs/general/specs/14. Name Resolution and Module Linking Specification.md`
- `docs/pbs/agendas/13. IR and Lowering Agenda.md`