[no subject]

[GLS@MIT-AI]

CC: NIL at MIT-MC
Browsing throughh the wonderful LISPM manual, an idea or two...

One thing I have always found tricky, even dealing with my own
code, is that often when I get a correctable error it is not clear
what the precise effect of proceeding or restarting will be.
As a simple example, WRNG-TYPE-ARG and WRNG-NO-ARGS errors in
MacLISP, though their names are similar, do completely different
things with the object given to proceed with.  Often in my own code,
for lack of a better error category, I use FAIL-ACT (I see this is
not a restriction in the LISP Machine), but then can't figure oout
what happens when I continue without looking at the code.
It occurs to me that an error message should always be accompanied
by a message describing the effects of proceeding or restarting
(or even, for that matter, aborting).
Now as long as the CERROR function in LISPM has these two flags
"proceedable-flag" and "restartable-flag", I would like to suggest
institutionalizing the following convention: a non-NIL value foor
such a flag shoould by convention be a string describing the result
oof taking the action permitted by that flag.  These strings should
be available to the handler.  The default handler should be
prepared to print them in response to ? or HELP.
Examples:
	(cerror "the value will be returned as that of the call"
		nil
		':inconsistent-arguments
		"The call to ~A used the inconsistent arguments ~A."
		the-fn the-args)
	(cerror "the value should be a stream to use instead"
		"I will try again to establish the CHAOSnet connection"
		':bagbiting-network
		"CHAOSnet site ~A is not responding"
		host)
[In the first example, I spuriously gave the-fn as an argument, which
ought to be there, contrary to the manual?]  For the second
example, typing HELP at the debugger might say, among other things:
	If you proceed (Control-C), the value should be a stream to use instead.
	If you restart (Meta-C), I will try again to establish the CHHAOSnet connection.
I haven't worked out all the details, but you get the general idea.
[By the way, haucome the error type :invalid-function doesn't let you
specify the function to use, instead of just aborting the whole call?]

An idea for CHECK-ARG is that it could use property lists in an
organized way too save typing.  The basic idea is (don't implement
it this way!!!):
	(defun check-arg (&quote varname &eval type-symbol &optional
				(predicate (fsymeval type-symbol))
				(description (or (get type-symbol 'check-arg-description)
					(string-append "something that satisfies "
						(cond ((symbolp predicate) ;ugh
							predicate)
							(t type-symbol))))))
		...
In this way  (CHECK-ARG A 'NUMBERP) [possibly without the quoote mark?]
would suffice, probably in conjunction with
(DEFPROP NUMBERP "a number" CHECK-ARG-DESCRIPTION).  [Again, this is
perhaps not the most flavorful way to go aboout it.]

Finally, it seems a shame that I cannot compute a function for
CHECK-ARG because oof its weird form/symbol hack on
its secoond "argument" -- it is reminiscent of the computed GO hack
or SSTATUS CHTRAN.  I might want to write
	(CHECK-ARG B (COND ((SYMBOLP A) (FUNCTION SYMBOLP))
			   ((STRINGP A) (FUNCTION STRINGP))
			   (T (ERROR ...)))
		   (FORMAT NIL "of the same type as ~A" A)).
Oh well.
-- Q