The straight story on ERRSET and related topics

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

ERRSET is an antiquated concept exactly because of the issue you raise.
It blurs the issue of control information and data information by having
a single exit point and trying to pass information at that exit point
which tells you which of two possible branches you might want to take.

IGNORE-ERRORS is the approximate analog of ERRSET in the error proposal
as it stands now, but the intent is not to solve all of ERRSET's problems.
The problems are there no matter how you define things so long as you have
to communicate failure information as data.

CONDITION-CASE (and more generally CONDITION-BIND) allow transfer of 
control to any of a number of continuations based on whether an error
occurs and on the characteristics of that error. This functionality 
has been used extensively in the entire family of Lisp Machine lisps 
and has proved quite effective. It provides the necessary flexibility
without getting caught up in issues such as the one you mentioned that
would indeed be caused if all it did was set itself up to lose in 
some cases such as the one you mention when the maximum return values
are already being returned.

By the way, unlike several useful extensions which have been traditionally
been available on the LispM only, the error system doesn't depend on any
special hardware that makes it impractical on other systems, as I think
the sample implementation I announced a while back demonstrates. It's more
just a matter of cultural compatibility that has until now kept this
kind of facility on the Lisp Machine.

-- The rest of this message is an aside to the CL-VALIDATION folks, who've
-- likely not followed the discussions on CL-ERROR-HANDLING.

It's important to understand that things like ERRSET and IGNORE-ERRORS
are likely to sometimes be just too blunt to treat each of the variety
of errors that might occur in an appropriate way. I am working under the
assumption that we will be able to provide you with something which is
much more flexible and much more what you'll need toward this end.

The discussion of IGNORE-ERRORS and CONDITION-CASE above are in
reference at Error Proposal #8. It's not an approved document and is not
even up for a vote, so probably shouldn't be called a "proposal".  It's
just the latest working draft that the group has available to make
comments on.  A large number of comments have been made which will have
to be addressed in a subsequent draft, so while technical commentary on
this draft is quite appropriate, and people should play with the spec
as written, no one should assume that anything in it is cast in concrete.

If you haven't seen error proposal #8, you might FTP the following two 
files:
 MIT-AI: COMMON; EPROP8 TEXT
 MIT-AI: COMMON; EPROP8 LISP
(Randy Parker at Palladian may already have gotten you a copy, dfm.)

The sample implementation is not intended for production work, but I
think that (modulo any out-and-out bugs) it implements more or less all
of the essential functional behavior of this particular proposal. Note
well, however, that only the spec is the document and the code is only
for illustrative purposes. Nothing in the code has any weight in the
standard itself. You're welcome (and encouraged) to try to code up your 
own implementation with or without looking at mine, and to submit any
gripes to CL-ERROR-HANDLING.

You can be added to CL-ERROR-HANDLING by sending mail to RPG@SU-AI
asking to be added. I'm assuming that people on CL-VALIDATION who worry
about errors are already on CL-ERROR-HANDLING or will now ask to be
added, so please let's move any further discussion back off to 
CL-ERROR-HANDLING and not cc CL-VALIDATION unless something new comes
up which would be of interest to all of them so their mailboxes are
not needlessly cluttered.