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 sperber@xxxxxx 12 Aug 2002 15:08 UTC

>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes:

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

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

Obviously, we're running into subtle issues concerning the semantics
of English.  Maybe some other native speakers can clarify how they
read this.

But the way I read SRFI 18, RAISE doesn't "raise an exception" itself:
it calls the exception handler.  One of the problems in SRFI 18 is
that the term "exception" is poorly defined.  In the sense of SRFI 34
("exception" = "exceptional situation"), the exceptional occurred
*before* the call to RAISE---the call itself is merely an indication
that it happened.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla