spec-conditions.md §1 and §2 and nothing else, because those two are worth having alone: signal returns Unit whatever it finds, a handler that returns normally leaves the signalling function to carry on, and with nothing matching it is a no-op. So none of §6's transfer machinery exists yet and no signature changed - which is the whole reason to do this step first. The runtime is a linked list. Establishing a handler is two stores and a push onto a frame on the establishing function's own stack, and signal with an empty stack is a null check, which is what §2 asks for. Popping is by frame rather than by count, so restoring what this one displaced is right even if something below it left the stack out of step. A condition's type is a hash of its name and not an index: an index would shift the moment a struct were added, and every handler a running program had already pushed would match the wrong type. The condition crosses as a pointer, since a handler runs while the signalling frame is alive and there is nothing to copy - but what the clause binds is the condition itself, the pointer being a hidden parameter and the name a slot loaded from it, so a handler passing c to something expecting the struct is not handed an address. A clause is lifted into a function of its own, because a handler runs from wherever the signal was and cannot be a branch in the function that wrote it. That gives two refusals, both by the house rule. A handler cannot see the establishing function's locals - that is a closure with an explicit environment, so a reference to one is refused for that reason rather than reported as an unknown name. And return inside a handler-bind body is refused, since the frames are popped on the way out and an early exit would leave them pointing into a function that has gone. Settled in advance for the next step: in a dev build every function is transfer-transparent, because a cell can hold anything and the honest answer to what it can call is anything. Same bargain as the indirect call, and it means redefinition acquires no new refusal class. Still open is whether the discriminated result is returned by value or through an out-parameter.
Description
Languages
OCaml
67.2%
Emacs Lisp
15.2%
C
10.4%
HTML
2.9%
Standard ML
2.8%
Other
1.5%