This page is part of the web mail archives of SRFI 12 from before July 7th, 2015. The new archives for SRFI 12 contain all messages, not just those from before July 7th, 2015.
>>>>> On Sun, 17 Oct 1999 08:26:24 -0400, Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> said: > Works fine for me. The barf exception gets passed to the outer > exception handler. Ah yes. The problem was my initial *current-exn-handler*. I *thought* the model implementation should work, but when my example didn't, I thought that I somehow misunderstood something about the call/cc and dynamic-wind interaction. > He may have convinced you, but he hasn't convinced me. As Per > Bothner said, exception systems are normally used to separate normal > from abnormal results. Why should sending abnormal results need to > be *very* cheap? Or even particularly cheap at all? It's the > normal results that have to be delivered quickly. This may be my ML experience showing. call/cc isn't part of portable ML, so people use exceptions to implement short-circuit evaluation and such-like that I guess you'd claim should be implemented directly with call/cc in Scheme. But I still think we should facilitate an inexpensive implementation, even if the reference implementation uses generic scheme. > References: <199910160912.FAA15873@xxxxxxxxxxxxxxx> Date: Sun, 17 > Oct 1999 00:22:18 -0400 From: Dave Mason <dmason@xxxxxxxxxxxxxxx> >> The SRFI-12 exception mechanism *is* cheap, but the *condition* >> mechanism isn't cheap at all. It requires (in general) creating an >> object for every raised exception. > You don't have to use conditions if you don't want to. (Perhaps > this is the reason for allowing non-conditions to be signalled?) > And if you do use conditions, there is nothing that requires that a > fresh condition be signalled each time. You can make one and use it > over and over again. The values in it can be changed via a side > effect, if you want. I'm not worried about explicit aborts in my program - I can do as you say. My concern is built-in low-level aborts. Like (/ x 0). If these dynamically create ``condition'' values, it will be expensive. >> I don't like the fact that it needs to do a dynamic-wind and a >> call/cc to set up an exception and the continuation is actually >> called whether or not an exception is raised (because it appears >> that dynamic-wind isn't values-aware). > I don't understand. `With-exception-handler' does a dynamic-wind > but not a call/cc. Given the handler's dynamic extent there is no > way to avoid the dynamic-wind (unless you go outside R5RS; some > implementations have shortcuts for dynamic variables). > The call/cc is needed in `handle-exceptions' to allow the handler to > return from from `handle-exceptions'. The call to the continuation > for the non-exception case isn't required, that is just the way they > wrote the code. I think that handle-exceptions is what virtually everyone will use (because the exception should run in the enclosing exception environment). Hence, they'll get both the call/cc and the dynamic-wind. > R5RS says that `dynamic-wind' should handle multiple values. Quite right. There was a detail of the implementation that I didn't understand, which led me to believe that it was dynamic-wind that was complaining when I tried to get rid of the normal-case continuation call. > I agree with you, although for different reasons. Restarts should > be left to another SRFI. Without restarts, WITH-EXCEPTION-HANDLER doesn't have to be exposed in the programming interface, and I see implementation approaches that could make HANDLE-EXCEPTIONS much lower cost. With restarts, you essentially need the dynamic-wind, call/cc pair to do HANDLE-EXCEPTIONS. If most built-in exceptions call the *current-exn-handler* with a constant argument (regardless of whether or not there are ``condition''s), an abort-only mechanism could certainly be as efficient as I'd like to see. ../Dave