[R6RS] Timeline for R6RS SRFIs
Wed Jun 1 23:23:08 EDT 2005
feeley at iro.umontreal.ca writes:
> To me this is strange because I expect raise to either not touch the
> dynamic environment, or to unwind it to the dynamic environment of the
> enclosing guard, but in the SRFI 34 specification it does a mix of
> both (unwinding for the exception handler, and not touching the rest
> of the dynamic environment).
As I said at the meeting, I'm not particularly attached to any
specific semantics to RAISE. (Within reason, of course.) Let me just
state the rationale for the one Richard and I chose:
- We wanted to give implementations the freedom not to unwind, so that
an exception handler could throw, say, to the debugger and allow it
to inspect the continuation of the RAISE. This seems important.
- Going back to the previous exception handler prevents the obvious
chance of infinite recursion.
Note also that the semantics of RAISE in SRFI 34 isn't specified in
terms of GUARD. This is important because I think you misunderstand
the semantics of SRFI 34, as explained below.
> This leads to unexpected behavior, for
> example consider:
> (with-output-to-file "X"
> (lambda ()
> (guard (exc
> (display "an exception was raised\n")
> If you look at this code you expect the output generated by the call
> to some-computation to go to the file "X", and if an exception is
> raised during the call to some-computation the message "an exception
> was raised\n" will go to the file "X". But in fact this is not the
> case with SRFI 34. Just consider this definition of some-computation:
> (define (some-computation)
> (with-output-to-file "Y"
> (lambda ()
> (raise "ooops")
If you look at the specification of GUARD in SRFI 34, you'll see:
34> That implicit cond expression is evaluated with the continuation and
34> dynamic environment of the guard expression.
So indeed you'll get the semantics you expect---I conjecture the
combination of RAISE and GUARD in SRFI 34 is exactly what you're
> In addition to this change of semantics, for R6RS I propose we drop
> with-exception-handler which can lead to infinite recursion when the
> exception handler raises an exception.
No, it cannot with the semantics of SRFI 34.
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
More information about the R6RS