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.
> 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