[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.



   Date: Mon, 12 Aug 2002 10:56:55 -0400
   From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx>

   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