# Dynamic Semantics - Execution Model Agenda

Status: Working agenda (pre-spec)  
Purpose: close the observable execution model for PBS before drafting the dynamic semantics spec

## 1. Context

Static semantics already fixes a large part of the source model, but several runtime-visible questions remain open:

- exact evaluation order,
- what counts as a trap versus an ordinary control-flow outcome,
- how `FRAME_SYNC` and deterministic safepoints constrain execution,
- what host calls are allowed to observe or perturb execution order.

These decisions should be closed before effect surfaces and memory/lifetime rules are written as normative dynamic semantics.

## 2. Decisions to Produce

This agenda must end with decisions for:

1. The observable sequencing model for expressions, statements, and blocks.
2. The normative evaluation order for arguments, receivers, selectors, and chained `apply`.
3. The abrupt-completion model: `return`, `break`, `continue`, result propagation, and traps.
4. The interaction between host calls, safepoints, and deterministic execution.

## 3. Core Questions

### Q1. Global execution model

- Is PBS execution defined as single-threaded per program instance in v1?
- Which execution steps are observable to user code, and which remain VM-internal?

### Q2. Expression evaluation order

- Is expression evaluation strictly left-to-right unless a construct says otherwise?
- For `f(a, b)` / `f apply (a, b)`, what is the order of evaluating callee, receiver, and argument expressions?
- For `f1 apply f2 apply x`, what is the runtime order implied by the right-associative parse?

### Q3. Single-evaluation guarantees

- Which constructs normatively evaluate subexpressions exactly once?
- Does that guarantee apply to `switch` selectors, `if` conditions, `opt else fallback`, `handle expr`, and `bind(context, fn_name)` context expressions?

### Q4. Blocks and control transfer

- How are statement sequencing and tail-expression evaluation defined inside blocks?
- At what point does `return`, `break`, or `continue` abort further evaluation in the current construct?

### Q5. Trap model

- Which runtime failures are traps rather than status values or compile-time rejection?
- Must trap categories be stable and named in the dynamic semantics spec?
- Are traps deterministic for the same program input and runtime capability set?

### Q6. Host interaction

- Can host calls introduce extra traps beyond ordinary PBS runtime failures?
- Where are safepoints guaranteed around host calls, allocation-heavy operations, and loop back-edges?

### Q7. Determinism boundary

- Which behaviors must be identical across conforming implementations?
- Which details may vary as implementation strategy without changing observable behavior?

## 4. Expected Spec Material

After discussion, this agenda should directly feed sections of `Dynamic Semantics Specification.md` covering:

1. execution state and step ordering,
2. evaluation order by construct,
3. abrupt completion and trap propagation,
4. host-call interaction constraints,
5. determinism requirements for conforming runtimes.

## 5. Non-Goals

- Revisiting grammar or typing unless the current surface is impossible to specify dynamically.
- Defining diagnostics wording in detail.
- Designing allocator APIs or collection libraries.

## 6. Inputs

- `1. Language Charter.md`
- `3. Core Syntax Specification.md`
- `4. Static Semantics Specification.md`
- `Heap Model - Agenda.md`