Date: Wed, 12 Feb 2003 20:37:43 -0500
   From: Marc Feeley <xxxxxx@IRO.UMontreal.CA>

   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