[plt-scheme] current-exception-handler

At Tue, 25 Mar 2003 04:04:11 -0500, Eli Barzilay wrote:
> Is there any reason for requiring `current-exception-handler' to
> escape? 

Most uses of `raise' are of the form

  (unless <something>
    (raise exn))
  <do normal work, disaster if not <something>>

but often more embeded in the function. Allowing a return from `raise'
would therefore require significant work.

> Without this restriction, it would have been possible to play
> cute games like making (/ foo 0) return +inf.0 or -inf.0, making
> references to unbound variables create globals (so the set! on
> undefined variables could be done in Scheme), or my favorite -- catch
> an exn:arity for not enough variables, and create a closure so
> something like (map cons) returns the Right Thing.

I agree with the "cute games" characterization. :) I don't think the
work is worthwhile for arbitrary exceptions.

There's one exception that does allow a return, `exn:break', but the
exception record contains a continuation for returning. We could allow
returning from other exceptions similarly ---- case-by-case for those
where it seems worthwhile.

> BTW#1: is in intentional that (/ 0 0.0) returns 0?

Yes. This is based on an interpretation of inexact 0.0 as an infinite
sequence of positive numbers that converge to 0. The same
interpretation makes (/ 1 0.0) = +inf.0 and (/ -1 0.0) = -inf.0.

> BTW#2: if continuation marks were mutable, wouldn't they be the same
>        as parameters?

Yes, when a continuation is restricted to a single thread (as in
MzScheme currently). But if continuations can change threads (as we'd
like to have soon), the most obvious semantics for mutatation
introduces bad sharing for parameters among threads.

To put it another way, continuation marks can implement fluid variables
as in Scsh. Parameters need to be something more like thread-fluids,
though.

Matthew