[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raise should not change continuation

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.



> The text in SRFI 18 you're referring to talks about primitives.
> SRFI 34 doesn't say anything about how primitives raise exceptions.
> 
> The specifications of RAISE and WITH-EXCEPTION-HANDLER in SRFI 18
> don't say anything about the dynamic environment or the continuation
> of the exception handler.  The single example given doesn't constrain
> this further, either.

But "raise" is a primitive so I don't see how a Scheme implementation
that conforms to SRFI 18 can also conform to SRFI 34 as currently
defined.

Note also that it is reasonable to view "raise" as the primitive
operation that raises exceptions.  Primitives, including those defined
in SRFI 18, can then raise exceptions simply by tail-calling "raise":

  (define (mutex-lock! mutex)
    (if (lock-the-mutex-and-check-if-abandoned mutex)
        (raise (make-abandoned-mutex-exception))
        #t))

Marc