Email list hosting service & mailing list manager

raise should not change continuation Marc Feeley (12 Aug 2002 12:09 UTC)
Re: raise should not change continuation sperber@xxxxxx (12 Aug 2002 12:45 UTC)
Re: raise should not change continuation Marc Feeley (12 Aug 2002 14:22 UTC)
Re: raise should not change continuation sperber@xxxxxx (12 Aug 2002 14:35 UTC)
Re: raise should not change continuation Marc Feeley (12 Aug 2002 14:57 UTC)
Re: raise should not change continuation sperber@xxxxxx (12 Aug 2002 15:08 UTC)
Re: raise should not change continuation Richard Kelsey (13 Aug 2002 01:17 UTC)

Re: raise should not change continuation Marc Feeley 12 Aug 2002 14:56 UTC

> 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