Comments on SRFI-39
shivers@xxxxxx
(26 Jan 2003 08:45 UTC)
|
Re: Comments on SRFI-39
Matthew Flatt
(26 Jan 2003 14:10 UTC)
|
Re: Comments on SRFI-39
sperber@xxxxxx
(26 Jan 2003 15:38 UTC)
|
Re: Comments on SRFI-39
Richard Kelsey
(11 Feb 2003 15:58 UTC)
|
Re: Comments on SRFI-39
bear
(11 Feb 2003 16:16 UTC)
|
Re: Comments on SRFI-39
Richard Kelsey
(11 Feb 2003 16:56 UTC)
|
Re: Comments on SRFI-39 Marc Feeley (13 Feb 2003 01:38 UTC)
|
Re: Comments on SRFI-39
Richard Kelsey
(13 Feb 2003 02:30 UTC)
|
Re: Comments on SRFI-39
sperber@xxxxxx
(13 Feb 2003 12:47 UTC)
|
Re: Comments on SRFI-39 Marc Feeley 13 Feb 2003 01:37 UTC
> Olin wrote: > > Spawning a thread, calling a function -- it's a dynamic nesting. > > The whole point to spawning a thread is that it isn't a dynamic > nesting. If you wanted dynamic nesting you wouldn't spawn a thread, > you would just call the thunk. The new thread's execution may happen > before the spawning call returns or it may happen after the spawning > thread has finished or the two may be interleaved. Where's the > nesting? Like Olin I think there is nesting. It is not a nesting of control but rather a nesting of dynamic context. So in code like this (list (thread-join! (thread-start! (make-thread (lambda () (f))))) (g)) I expect both (f) and (g) to see the same dynamic environment. In fact that code is (essentially) equivalent to (list (f) (g)) 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. So code like this (where f is a function with no side-effect that terminates and which accesses parameter param1) (let ((x (f))) (parameterize ((param1 ...)) (+ x (g)))) yields the same result as (let ((x (delay (f)))) (parameterize ((param1 ...)) (+ (force x) (g)))) 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. A similar thing can be said of the FUTURE form of Multilisp. It can be viewed as an annotation that indicates that the computation of the body is to be done concurrently. This view leads to the Katz-Weise semantics for continuations (see: Morry Katz and Daniel Weise. Continuing Into the Future: On the Interaction of Futures and First-Class Continuations. In Proceedings of the 1990 ACM Conference on Lisp and Functional Programming, pages 176-184, June 1990.) which I implemented in my PhD thesis. Given the obvious link between threads and FUTUREs, I think this semantics should also apply to threads. Marc