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