[R6RS] Suggested changes to exception/condition SRFIs

[Michael Sperber]

As promised, here's a summary of the changes that have been suggested
so far.  These are all in the nature of clarifications or extensions
to the SRFIs---no outright changes have been proposed yet, I believe.

SRFI 34 ("Exception Handling for Programs")

The specification of `raise' is tightened, and a new
`raise-continuable' procedure (also adhering to SRFI 34's
specification of `raise') is added as follows:

(raise obj)
   Raises a non-continuable exception by invoking the current
   exception handler on obj. The handler is called with a continuation
   whose dynamic environment is that of the call to `raise', except
   that the current exception handler is the one that was in place for
   the call to `with-exception-handler' that installed the handler
   being called.  The continuation of the handler will raise a
   non-continuable `&non-continuable' exception.

(raise-continuable obj)
   Raises a continuable exception by invoking the current exception
   handler on obj. The handler is called with a continuation that is
   equivalent to the continuation of the call to `raise-continuable'
   with these two exceptions: (1) the current exception handler is
   the one that was in place for the call to `with-exception-handler'
   that installed the handler being called, and (2) if the handler
   being called returns, then it will again become the current
   exception handler.  If the handler returns, the value(s) it
   returns become(s) the value(s) returned by the call to
   raise-continuable.

Moreover, some information should be given about the behavior of the
default exception handler.  I suggest that it should handle all
&serious conditions in the R6RS by interrupting the program and
reporting that an exception has been raised, and displaying some
information about the condition object that was provided.  Presumably,
the default handler would just return when passed any other
("non-serious") condition.

SRFI 35 ("Conditions")

The premise of the SRFI is extended to include violations, as
suggested by Will.  This means more condition types.  Currently,
Will's list includes:

&condition
  &message
    &warning
  &serious
    &error
      &non-continuable   ; handler wasn't expected to return
      &implementation-restriction
        &no-infinities   ; cannot represent +inf.0, -inf.0
        &no-nans         ; cannot represent +nan.0, -nan.0, nan.0
      ...
    &violation
      &nonstandard
      &defect
        &lexical
        &syntax
          &undefined     ; reference or assignment to undefined variable
        &domain
          &type
            &boolean
            &symbol
            &char
            &vector
            &procedure
            &pair
            &number
              &complex
              &real
              &rational
              &integer
              &exact         ; not an exact complex number
                &exact-rational
                  &exact-integer
                    &index   ; not an exact non-negative integer
                    &fixnum  ; not an exact integer within fixnum range
              &inexact       ; not an inexact complex number
                &inexact-real
                  &flonum    ; not a flonum
                  &inexact-rational
                    &inexact-integer
            &string
            &llobj       ; not a list-like object (null or pair)
          &list          ; not a proper list
          &alist         ; some element is not a pair
          &immutable
        &incompatible    ; arguments okay singly but not together
          &index         ; index out of range
        &result          ; result not well-defined
        ...

Furthermore, presumably more would be added to refine this hierarchy,
and to cover I/O and hash tables.  (I've removed the references to I/O
from Will's list for now pending more discussion of the I/O
issue---not intended as a statement of disagreement.)

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