Re: raise should not change continuation
Richard Kelsey 13 Aug 2002 01:16 UTC
Date: Mon, 12 Aug 2002 10:56:55 -0400
From: Marc Feeley <xxxxxx@IRO.UMontreal.CA>
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.
The terminology is a bit confusing, partly because there doesn't
seem to be anything in SRFI 18 that says what a 'primitive' is.
Are all procedures in SRFI 18 primitives? There is a section
labelled 'procedures' but none labelled 'primitives'.
I agree with Mike that there is an difference between saying that
'FOO raises an exception under such and such circumstances' and
saying that 'RAISE calls the current exception handler'.
That being said, I now think that it would require fairly
narrow reasoning to say that SRFI 34 is compatible with SRFI 18.
They appear to be compatible from the descriptions of RAISE and
WITH-EXCEPTION-HANDLER in SRFI 18; I had missed the generality
of the 'primitives and exceptions' paragraph. I suggest that
we remove the compatibility comment from SRFI 34.
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))
This would imply that MUTEX-LOCK! is not a primitive, by the
way. You can see the possibilities for confusion.
-Richard