This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.
I apologize for the long delay in moving SRFI-39 forward... There is clearly discord in how dynamic binding should behave in the presence of threads. On the other hand, when threads are not involved, it seems that we all agree on how dynamic binding should work. It appears that the best solution in this case is to separate the issues into several SRFIs. SRFI-39 can specify the parameter API and the behaviour in the absence of threads. It will be up to individual thread SRFIs to specify a particular semantics to dynamic binding. If anyone objects to this approach please let me know. Otherwise I will revise the SRFI accordingly. There is however the issue of the interaction of dynamic binding and the DELAY special form. In my opinion the body of the DELAY form should be evaluated in the same dynamic environment as the DELAY form itself. For example in the code (with-output-to-file "foo" (lambda () (let ((x (delay (display "hello")))) (with-output-to-file "bar" (lambda () (display "world") (force x)))))) we want "hello" to go to the file "foo" and "world" to go to the file "bar". This is consistent with the concept of delaying the computation (you only want to change **when** the computation is performed, not **what** the computation performs). If this inheritance did not happen, the DELAY form would lose modularity (in the sense that the one writing the DELAY expression would have to take into account all the possible places where the promise is forced). This implies that if an exception is raised by the body of a DELAY form, it is the exception handler that was current at the DELAY form that is invoked. I think this makes sense, but I'd like a discussion on this before moving ahead with the rewrite. Marc