[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: threads & dynamic environment & continuations
> 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
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
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-set! var-name expression)
Note that in this scheme, dynamic variables and lexically scoped
variables are completely independent.