ERROR SIGNALLING FUNCTIONS

[David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>]

I don't recall seeing your comments before; perhaps your original
message was swallowed by some mail system problem.  It wouldn't
be the first time.

Your comments are well taken, but I think underlying this there is a
fundamental disagreement about what Common Lisp is for.  Such constructs
as check-type and assert are intended for internal checking within a
program; they are certainly not intended as a user interface for users
of an application program.  When a check-type signals an error, it is
assumed that the user is thrown into the debugger.  Supplying a new
value is a debugger function suitable for someone who understands the
program and the particular error that occurred.  An application program
that is trying to conceal its Lisp underpinnings from its user and
present some consistent facade that differs from the facade the system
presents to Lisp programmers would not allow this error to get into
the debugger.  Presumably it would say "Internal error; the program
is broken".

Indeed, Common Lisp in general is a system programming language and is
not itself a framework for constructing user interfaces.  At least not
yet; this seems like a good area to address in a "second generation"
of Common Lisp.  But I think the conscious decision we made to concentrate
on the easier areas first was wise, considering how long it has taken
just to define the language in all of its details.

Also you should note that check-type and assert are convenient abbreviations,
not the most general error signalling mechanism.  So it's supposed to be
okay that you cannot do all possible error signalling with them, for instance
you can't compute an error message at run time.  Perhaps this design
decision was wrong; I couldn't say.

The condition system that I intend to propose after the basic language
has been squared away addresses these issues.  It is based on the Lisp
Machine condition system, with some improvements and simplifications.