2.19.3 Rationale

The dynamic environment is the structure which allows the system to find the value returned by the R5RS procedures current-input-port and current-output-port. The R5RS procedures with-input-from-file and with-output-to-file extend the dynamic environment to produce a new dynamic environment which is in effect for the dynamic extent of the call to the thunk passed as their last argument.

These procedures are essentially special purpose dynamic binding operations on hidden dynamic variables (one for current-input-port and one for current-output-port). The purpose of this SRFI is to generalize this dynamic binding mechanism (which exists in all R5RS compliant systems) to allow the user to introduce new dynamic variables and dynamically bind them.

General dynamic binding mechanisms exist in several implementations of Scheme under various names, including “fluid” variables and parameter objects. The parameter objects specified in this SRFI are compatible with the semantics of all implementations of Scheme we know which currently support parameter objects (in the sense that it is possible to implement this SRFI so that old code works the same as before). We believe Chez–Scheme was the first implementation of Scheme to have used parameter objects.

In the presence of threads, the dynamic binding mechanism does not behave the same way in all implementations of Scheme supporting dynamic binding. The issue is the relationship between the dynamic environments of the parent and child threads when a thread is created. In Scheme 48 the child gets a fresh dynamic environment where (typically but not necessarily) all the bindings are to their initial value.

In MzScheme and Gambit–C the child is given a dynamic environment inherited from the parent. In this inherited dynamic environment the dynamic variables have the same values as the parent’s dynamic environment. However, in MzScheme the cells bound to the dynamic variables in the child are distinct from those of the parent (i.e. an assignment of a value to a dynamic variable is not visible in the other thread). In Gambit–C the child and parent dynamic environment share the same cells (i.e. an assignment of a value to a dynamic variable is visible in the other thread). Note that in the absence of assignment to dynamic variables the MzScheme and Gambit–C approaches are equivalent.

Given that there are semantic differences in the presence of threads and that there are valid reasons for choosing each semantics, this SRFI does not specify the semantics of parameter objects in the presence of threads. It is left to the implementation and other SRFIs which extend this SRFI to specify the interaction between parameter objects and threads.