Errors in LISP Machine code

[gls at MIT-AI (Guy L. Steele, Jr.)]

CC: GLS at MIT-AI

I'd like to suggest that a little more thought be put into
error recovery in LISP Machine software.  We have this
wonderful CERROR function which ought to be used more.
For a better user interface, it should ideally be very
easy for the user to retry or restart or whatever.
Some parts are very good, offering you a range of options
(e.g. Y, N, E, or P?); others just crap out and the
best you can do is return a value from some function,
possibly after pulling off a side effect (which is difficult
at best because all the goodies of interest are hidden
away in compiled local variables
	[by the way, people, one of the claimed advantages
	of dynamic scoping was that debugging is easier because
	you can just type the name of a variable and see the
	value when in a debugger -- whereas for lexical scoping
	you need a more complicated thing that can grovel over
	the environment.  But in the current scheme of things
	I find myself typing A and L a lot and groveling arond
	trying to find things.  The new window system debugger
	may help some -- but that technology would also help
	lexical scoping too.  Before I end this flame, I'd like
	to put in a good word for the DEFAULT being for the
	compiler to include all debugging information, including
	names of locals and the kitchen sink, in all FEF's,
	for debugging purposes.  Also a reverse compiler would be
	a lot more useful than the crocky disassembler.]
where they are hard to find).  I said I wouldn't hack FORMAT
any more, but if other people will think harder about error
recovery I promise to fix up all the uncorrectable errors
in FORMAT to recover more gracefully.

I suggest that the flags to CERROR (proceedable-p and restartable-p)
should, if non-nil, be strings describing what will happen
if that action is taken.  This information should be printed
along with the error message, or something.