This page is part of the web mail archives of SRFI 34 from before July 7th, 2015. The new archives for SRFI 34 contain all messages, not just those from before July 7th, 2015.
Date: Sun, 1 Sep 2002 13:55:02 -0700 (PDT)
From: bear <bear@xxxxxxxxx>
I am concerned that the "current exception handler" seems to be
global -- a property of the program rather than an individual
thread.
No, it is a property of a thread of execution. It is defined
in terms of CALL-WITH-CURRENT-CONTINUATION and DYNAMIC-WIND.
The reference implementation does use a global variable and it
might or might not work in a multi-threaded Scheme, depending
on whether switching threads runs the DYNAMIC-WIND thunks.
If it does, then the threads can safely share the single global
variable. If switching threads doesn't run the DYNAMIC-WIND
thunks, then the current exception handler would have to bound
using some kind of thread-local environment. Or not. Given all
the different possible thread models that could be grafted on to
Scheme it isn't possible for SRFI-34 to define a single 'correct'
interaction between threads and exception handlers.
The business of passing around thunks and continuations as objects
as in SRFI 34 seems to me to get in my way and complicate things,
and I don't think it actually provides more generality or
functionality.
SRFI 34 is defined in terms of R5RS, which doesn't give access
to stack frames. Instead it has procedures, continuations, and
DYNAMIC-WIND, so that is what we use. The generality it provides
is that it runs in implementations of R5RS. I don't see how that
can be done using stack frames.
That being said, I would be surprised if it were impossible to
implement a system with semantics equivalent to yours in R5RS,
even though I am not sure exactly what that semantics is.
Continuations, DYNAMIC-WIND, and proper tail-recursion can all
be thought of as ways of manipulating stack frames.
-Richard