[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on SRFI-39

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

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.