error proposal

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

Now that Moon's error proposal has made it out to the mailing list, I
can say that I am strongly in favor of it.  The old proposal, as it
evolved through various versions, ended up tying down all the wrong
things.  It is essential that the white pages include a good set of
portable mechanisms for signalling errors, but I believe that the style
of user interaction will vary so much from one implementation to another
that it is a major mistake to say too much about error handling and user
dialogues.

Of course, the Lisp we are doing will have a condition handler that
looks very much like the one specified in Laser.  What this proposal
does is to give us some room to evolve to something better in the
future, as well as correcting some things that are already bothering us.

On the issues:

    Should the manual include some way to make WARN behave like CERROR
    (pause in the debugger after each warning)?

I advocate a *BREAK-ON-WARNINGS* switch.  We'll probably add such a
switch to our implementations in any event (a compatible extension)
since I think it would be useful between now and when the "future
condition-handling system" appears.


    I'm willing to change the syntax of ASSERT...

The ASSERT Moon proposes above in the body of the proposal looks OK to me.

    Should the following function (ABORT-PROGRAM) exist?

I agree with Moon: let's leave it out for now.  There are funny issues
about how this would interact with various top-levels (editor-based,
etc.) and with breaks and embedded command loops.

    In CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, I have specified that
    subforms of the references may be evaluated multiple times.  Would it
    be better to specify that they are always evaluated exactly once?  

I think it's a mistake to specify that subforms here are evaluated only
once.  The reading of these forms (to present the current values to the
user) and the setting of new values could be very far apart, with
perhaps a breakpoint and some arbitrary environment-prowling by the user
in between.  We should allow implementors to have some flexibility here.

    DEFTYPE should provide a way to specify the default description string,
    used when that type is the second subform of CHECK-TYPE and there is no
    third subform.  Is this what the documentation string in DEFTYPE is for,
    or is that something else?

I think it would be confusing to snarf DEFTYPE's documentation string
for this purpose.  The "type name in English" and the documentation
string might have similar contents, but the former must obey funny
format rules that do not apply to any other kind of documentation.  I
think that these ought to be separate arguments to DEFTYPE.

-- Scott