Re: KMP's proposal

[Mary <Fontana%CSL60%ti-csl.csnet@csnet-relay.arpa>]

Last week, I tried to get a copy of the file <FAHLMAN>KMP-ERROR.TXT to
see if it was the same as the message Kent sent out last February
titled "stripped down version of lispm error system".  Using FTP from
UT Austin always resulted in "file unknown".  Is the file still
around?
Here's my suggestions:

1. I think condition handlers should be searched from the inside out.
This works best when you evaluate something while in a read-eval-print
loop.  The read-eval-print loop could have a condition-bind on a
particular set of errors (like too-few-arguments, function-undefined).
A function evaluated in this loop might have a condition-bind for
these same errors.  The function's handlers should be tried first.

Kent talked about default handlers in his memo, "Exceptional
Situations in Lisp".  Whether or not the order should be reversed for
default handlers is unclear to me.

2. I think we need restart handlers to set up proceed options which do
a non-local transfer of control.  On a lisp machine, when the debugger
prints the proceed options for an error, it includes the restart
proceed options (one of which is usally assigned to ABORT).  Any
condition handler or debugger could suggest to proceed by restarting
at a certain point in the program.  We need a CONDITION-RESTART
special form.

3. Class hierarchy of conditions as well as proceed options should be
available.  This was discussed in Kent's memo on exception handling.

4. The common lisp functions ERROR and CERROR should include a
signal-name (condition-type) argument.

5. I recommend including the lisp machine's CONDITION-CASE,
CONDITION-CALL, CATCH-ERROR and IGNORE-ERRORS.  All of these could be
implemented with CONDITION-BIND.
-------