This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
> I don't believe the spec states the (obvious) fact that preemptively switching > between two threads, or yielding or otherwise blocking does *not* cause > DYNAMIC-WIND's to fire. (By the way, I think DYNAMIC-WIND is a very bad idea, > in general. I opposed its introduction because of its bad interaction with the > notion of thread concurrency, and here we are, tripping over it.) I also oppose dynamic-wind for those reasons and if I could only change one thing about R5RS it would be to remove dynamic-wind (the second thing would be to remove multiple values, but that is more controversial, are you listening Siskind?). > I think the current document should state these things explicitly. To sum up: > - dynamic env is part of the continuation, > - hence, throwing to a continuation changes the dynamic env. This was so "obvious" to me that I did not mention it. On the other hand, is it the role of SRFI 18 to specify this, or a dynamic environment SRFI? As for call/null-continuation, you can get the same result with call-with-current-continuation, if you also have dynamic variables. I.e. you capture the primordial continuation of the thread and bind that to a dynamic variable that you can then use to return to the primordial continuation. Should SRFI 18 specify a mechanism for manipulating the dynamic environment? I'm fond of: (dynamic-define var-name expression) (dynamic-let ((var-name expression)) body) (dynamic-ref var-name) (dynamic-set! var-name expression) Note that in this scheme, dynamic variables and lexically scoped variables are completely independent. Marc