> 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