87 lines
3.4 KiB
Markdown
87 lines
3.4 KiB
Markdown
# 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`
|