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.
Date: Wed, 12 Feb 2003 20:37:43 -0500
From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx>
Like Olin I think there is nesting. It is not a nesting of control
but rather a nesting of dynamic context.
Can you define 'dynamic context'? Why doesn't it include the
dynamic-wind state? Having dynamic-wind's notion of dynamic
state is complicated enough. Adding another seems baroque.
I can understand having threads inherit the dynamic state of
their spawning thread (which is not to say that I would like
it), but only if the entire dynamic state is inherited.
In a previous message Michael Sperber pointed out that the effect of
DELAY on the dynamic environment is not specified by the SRFI. This
is an oversight. For consistency with make-thread, the body of the
DELAY must also inherit the dynamic environment of DELAY's continuation.
[...]
This makes sense if you view the DELAY form as an annotation
indicating only that the computation is to be delayed. You don't want
the computation to be different, you simply want to displace it in
time.
That is one way to view DELAY, but certainly not the only one.
I might want the computation to be run later precisely because
it will produce a different answer then. And if it is supposed
to produce the same answer shouldn't it close over the store as
well? It seems unnecessarily complex to make DELAY close over
more than LAMBDA does.
-Richard