This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
On the whole, I like Marc's design very much. I would like to comment on the interplay between threads, dynamic environments and continuations. Essentially, a continuation is a snapshot of thread state. Think of a thread as a virtual PC. Throwing to a continuation loads that PC's context. It is well understood in the SML/NJ community (which has been grabbing continuations, dealing with dynamically bound exceptions, and hacking threads for > 10 years), that the dynamic environment is *part of the continuation*. So throwing to a continuation discards the current dynamic environment, and installs the one packaged up with the continuation to which we are throwing. CALL/CC grabs the dynamic environment at the point of call and packages it up when it builds the reified continuation. Finally, you need to add some kind of (call-terminally thunk) or (call/null-continuation thunk) procedure to allow one to *drop* the dynamic environment in order to prevent space leaks in some thread cases. Such a function calls THUNK with a continuation that (1) either kills the process or is undefine and (2) has no dynamic environment. That is, *don't* return through that continuation. It's only purpose is to sever ties with the current continuation (i.e., CALL-TERMINALLY's continuation). I don't believe the spec states the (obvious) fact that preemptively switching between two threads, or yielding or otherwise blocking does *not* cause DYNAMIC-WIND's to fire. (By the way, I think DYNAMIC-WIND is a very bad idea, in general. I opposed its introduction because of its bad interaction with the notion of thread concurrency, and here we are, tripping over it.) I think the current document should state these things explicitly. To sum up: - dynamic env is part of the continuation, - hence, throwing to a continuation changes the dynamic env. There has been some discussion about the merits of keeping or dropping continuations at all. I *strongly* support keeping continuations in Scheme. They are an important conceptual and programming tool. -Olin