6.3 On the meaning of dynamic extent termination

The concept of dynamic extent termination is defined by MMCK Exceptional Conditions’s unwind–protection mechanism and it is not a standard Scheme concept. In this discussion, we consider the syntax use:

(with-unwind-handler ?unwind-handler ?thunk)

the procedure ?unwind-handler is called when the dynamic extent of the invocation of ?thunk terminates; dynamic extent termination is different from dynamic extent exiting as determined by dynamic-wind. When the execution flow exits the dynamic extent of a function call: such extent might also terminate, but not all the exits are also terminations.

The dynamic extent of a call to ?thunk is terminated, and so ?unwind-handler is invoked, when:

• ?thunk performs a normal return. ?unwind-handler is applied to the symbol ‘return’.
• ?thunk raises a continuable or non–continuable exception that is intercepted by a use of guard, but only when a clause of guard has a test expression returning non–false.

  (guard (E (?test ?expr))
    (with-unwind-handler ?unwind-handler ?thunk))
  

  This is what happens:

  1. The clause’s ?test expression is evaluated in the dynamic environment of the use of guard and it returns non–false.
  2. ?unwind-handler is applied to the symbol ‘exception’, in the dynamic environment of the use of with-unwind-handler, and its return values discarded.
  3. The clause’s ?expr is evaluated in the dynamic environment of the use of guard and its return values are returned to the continuation of guard.
• ?thunk executes a use of the syntax return, as defined by the library (mmck exceptional-condition), to escape from a form that encloses an unwind–protection syntax. ?unwind-handler is applied to the symbol ‘escape’.

  As bound by the returnable: the syntax return reinstates a continuation at the beginning or outside of returnable and performs special operations to terminate the dynamic extent of the call to ?thunk in an unwind–protection form.

The dynamic extent of a call to ?thunk is not terminated, and so ?unwind-handler is not invoked, when:

• ?thunk raises a continuable exception by calling raise-continuable, and such call performs a normal return to ?thunk.
• ?thunk raises a continuable or non–continuable exception and an exception handler terminates the process (for example by calling exit).
• An escape procedure is called from within ?thunk to reinstate a continuation outside ?thunk, and the call to the escape procedure is not interfaced with the unwind–protection mechanism to terminate the dynamic extent of the call to ?thunk.

About the termination of the dynamic extent of ?thunk, we must acknowledge that:

• There is no guarantee that: after exiting (without terminating) the dynamic extent of ?thunk by reinstating a continuation, such extent will be reentered later and continue to termination.
• If the dynamic extent of ?thunk is terminated and an attempt to reenter ?thunk is performed: an exception is raised with compound condition object containing a &non-reinstatable component (see &non-reinstatable).
• Obviously, if a call to ?unwind-handler raises an exception: the clean–up operations performed by ?unwind-handler may fail, in whole or in part, possibly leaving behind unreleased resources.
• If the call to ?thunk raises an exception and a use of guard intercepts it: if a test expression in a clause of guard raises an exception, the ?unwind-handler may not be called.

  While it is possible to raise any object: it is better to always raise a condition object (possibly compound), so that the test expressions in guard uses can just be condition object type predicates; such predicates never raise exceptions.

If ?unwind-handler raises an exception: such exception is blocked and discarded.

This document describes version 0.1.0-devel.1 of MMCK Exceptional Conditions.