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 12:45 UTC

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

>> (raise obj )
>>
>>   Invokes the current exception handler on obj . The handler is called
>>   in the dynamic environment of the call to raise , except that the
>>   current exception handler is that in place for the call to
>>   with-exception-handler that installed the handler being called. The
>>   handler's continuation is otherwise unspecified.

Marc> I'm sorry to say, but this definition is inconsistent with SRFI 18
Marc> because of this section in SRFI 18:

Marc>  Primitives and exceptions

Marc>    When one of the primitives defined in this SRFI raises an exception
Marc>    defined in this SRFI, the exception handler is called with the same
Marc>    continuation as the primitive (i.e. it is a tail call to the
Marc>    exception handler). This requirement avoids having to use
Marc>    call-with-current-continuation to get the same effect in some
Marc>    situations.

Marc> In SRFI 18 the exception handler must be called with the same
Marc> continuation as "raise" (and consequently the same dynamic
Marc> environment and exception handler).

Why is this inconsistent?  SRFI 34 doesn't specify a behavior
different from that of SRFI 18.  It merely leaves part of the behavior
unspecified.

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