> 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