perm filename CLERHA.MSG[COM,LSP]3 blob sn#785173 filedate 1985-02-08 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Error Handling Subgroup.
In order to mail to this group, send to the address:

		CL-Error-handling@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLERHA.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Error-handling-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay
Kent Pitman		MIT		kmp@mc
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Jim Large		PERQ		Jim.Large@cmu-cs-spice
Mary Fontana		TI		fontana.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-common-error@mc
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Alice Hartley		BBN		hartley@bbn
David Moon		Symbolics	moon@scrc-stonybrook
Eric Benson		Lucid		eb@su-ai
Dan Weinreb		Symbolics	DLW@scrc-stonybrook

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂23-Sep-84  1612	RPG  	Introduction  
To:   cl-error-handling@SU-AI.ARPA    
Welcome to the Common Lisp Error Handling Subgroup.
In order to mail to this group, send to the address:

		CL-Error-handling@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLERHA.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Error-handling-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay
Kent Pitman		MIT		kmp@mc
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Jim Large		PERQ		Jim.Large@cmu-cs-spice
Mary Fontana		TI		fontana.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-common-error@mc
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Alice Hartley		BBN		hartley@bbn
David Moon		Symbolics	moon@scrc-stonybrook
Eric Benson		Lucid		eb@su-ai
Dan Weinreb		Symbolics	DLW@scrc-stonybrook

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂02-Oct-84  1312	RPG  	Chairman 
To:   cl-error-handling@SU-AI.ARPA    
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.

The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show. 

Any takers?
			-rpg-

∂03-Oct-84  1753	KMP@MIT-MC 	Breaking radio silence, chairing CL-ERROR-HANDLING   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Oct 84  17:53:15 PDT
Date: 3 October 1984 20:24-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  Breaking radio silence, chairing CL-ERROR-HANDLING
To: RPG @ SU-AI
cc: cl-error-handling @ SU-AI
In-reply-to: Msg of 02 Oct 84  1312 PDT from Dick Gabriel <RPG at SU-AI.ARPA>

    Date: 02 Oct 84  1312 PDT
    From: Dick Gabriel <RPG at SU-AI.ARPA>

    ... I suggest that people volunteer for chairman ...

I'm willing to chair this list if people are agreeable to that.
-kmp

∂13-Oct-84  1442	RPG  	Chairman 
To:   cl-error-handling@SU-AI.ARPA    

Kent Pitman volunteered to be chairman of the Error Handling subgroup.  If
he is willing, and no one else volunteers, he will become chairman. Please
respond by October 24. At the end of this month I want to see some ideas
and proposals coming in on this mailing list.

			-rpg-

∂13-Oct-84  1521	HANDERSON@CMU-CS-C.ARPA 	Proposals and time limit 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Oct 84  15:09:25 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 13 Oct 84 18:10:12-EDT
Date: Sat, 13 Oct 1984  18:10 EDT
Message-ID: <HANDERSON.12055196128.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-error-handling@SU-AI.ARPA
Subject: Proposals and time limit
In-reply-to: Msg of 13 Oct 1984  17:42-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


Presumably there are already some people listening.  I'd like to suggest that
before proposals are thrown around, we start discussing just what an error or
condition is, how the two interact, and what are necessary vs. gratuitous
aspects of a condition system (the last of which (especially) should be
answered by some reasonably experienced and uncommitted people).

-- Steve

∂13-Oct-84  1626	KMP@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Oct 84  16:24:26 PDT
Date: 13 October 1984 19:24-EDT
From: Kent M Pitman <KMP @ MIT-MC>
To: Handerson @ CMU-CS-C
cc: cl-error-handling @ SU-AI
In-reply-to: Msg of Sat 13 Oct 1984  18:10 EDT from Steven <Handerson at CMU-CS-C.ARPA>

    Date: Sat, 13 Oct 1984  18:10 EDT
    From: Steven <Handerson at CMU-CS-C.ARPA>

    ... I'd like to suggest that before proposals are thrown around, 
    we start discussing just what an error or condition is, how the 
    two interact, and what are necessary vs. gratuitous aspects of a 
    condition system ...

I'd like to start even more slowly by just defining the terms
to be used in our discussions.

The CL manual uses the terms "error", "signal", and "handle". It does
not use the term "condition", but perhaps we should introduce that
distinction (as the LispM does). My experience with using the LispM 
says that it is an important distinction to make.

In a manual put out by Symbolics entitled "Signalling and Handling
Conditions" they standardize on essentially the following terms (the
definitions of which I have mostly paraphrased here):

  The term "event" refers to "something that happens" during the 
   execution of a program.

  The term "condition" refers to a class of object which is associated
   with the occurrence of a particular kind of event in a program.

  The term "signal" refers to the action of reporting an event to other
   parts of the program which may be interested.

  The term "handle" refers to an action taken by some program as a 
   result of a signal.

  The term "error" denotes a particular type of condition which is 
   associated with an event that has been detected by a program as not 
   part of its contract. When an error condition is signalled, the 
   program may not proceed without the condition having been handled 
   somehow. This implication is not necessarily true of all conditions--
   only of error conditions.

I recommend that for our purposes the term "event" and the term
"condition" be merged and that both "something that happens" and the
object which represents that "something" be referred to as the
"condition". The rest of the terminology I recommend we adopt 
essentially as I've described it here.

As mentioned in the manual (p428), CL contains primitives to signal
errors, but no primitives for handling them. One important function of
this discussion must be to identify the primitives we need.

Also, since the manual does not treat [non-error] conditions,
it follows that CL has no primitives for signalling such conditions.
We may also want to decide if there should be some mechanism for
treating such conditions.

Does anyone disagree with any of the above and want to propose
modifications or alternatives?  First order of business should be to
standardize on as many terms as we can agree are useful so that we don't
end up talking across purposes.

-kmp

∂16-Oct-84  1331	DLW@SCRC-QUABBIN.ARPA 	Terminology of error-oloy  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  13:31:13 PDT
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 91365; Mon 15-Oct-84 14:55:14-EDT
Date: Mon, 15 Oct 84 14:54 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-STONY-BROOK.ARPA>
Subject: Terminology of error-oloy
To: KMP@MIT-MC.ARPA
cc: cl-error-handling@SU-AI.ARPA
In-Reply-To: The message of 13 Oct 84 19:24-EDT from Kent M Pitman <KMP at MIT-MC>
Message-ID: <841015145406.2.DLW@CHICOPEE.SCRC.Symbolics>

Your summary of the terminology is good.  Jan Walker and I established
the terminology while she was editing the document, and the word "event"
was introduced because it really turned out to be necessary to have a
word for that concept in order to be accurate and clear at the same
time.  You'll notice that the word "event" is hardly ever used after the
first few pages, which explain the fundamental concepts of the condition
mechanism.  It might turn out to be useful in this discussion; in any
case, it's likely that its meaning will be clear from context.

The exact definition of what constitutes an "error" is something that
has eluded me for a long time.  If a program has a bug such that it
computes the wrong result, but at no time actually signals anything,
then it has violated its contract and therefore is in error
nevertheless.  It can also be argued that if (/ 1 0) signals the
sys:divide-by-zero condition, then it was operating properly and
according to its contract, and therefore no error occurred.  On one
hand, I'd be happy to see a good resolution of these issues.  On the
other hand, it's probably a philosophical can of worms that need not be
opened in order for us to proceed.  I just thought I should mention that
there doesn't seem to be a completely good definition of "error".

One thing that we should all agree to is that an error is a synchronous
event; that is, it happens as a direct result of the execution of a
program, and it happens at a particular point in that program.  The
occurrance of an asynchronous event, like an interval timer going off,
or a network connection being broken due to a timeout, or any kind of
asynchronous "interrupt", is not an "error" in the sense we mean here.

∂16-Oct-84  1419	jml@cmu-cs-spice.arpa 	Re: Terminology of error-oloy   
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  14:19:15 PDT
Date: Tuesday, 16 October 1984 17:12:18 EDT
From: Jim.Large@cmu-cs-spice.arpa
To: "Daniel L. Weinreb" <DLW@scrc-stony-brook.arpa>
cc: cl-error-handling@su-ai.arpa
Subject: Re: Terminology of error-oloy
Message-ID: <1984.10.16.20.50.30.Jim.Large@cmu-cs-spice.arpa>
In-Reply-To: <841015145406.2.DLW@CHICOPEE.SCRC.Symbolics>

   It might be easier to distinguish an "error" from the broader class of 
"conditions" by looking only at the point where the error is signalled.

   Perhaps an "error" is a condition signalled by some routine when
that routine has been given inconsistent inputs (its contract has been
violated by its caller) and it does not know what else to do.

   By this definition, division-by-zero is an error because it is the 
condition raised by the divide instruction when divide is given illegal
operands.
					-- Jim Large

∂16-Oct-84  1547	KMP@MIT-MC 	Terminology of error-oloy   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  15:47:17 PDT
Date: 16 October 1984 18:49-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  Terminology of error-oloy
To: Jim.Large @ CMU-CS-SPICE
cc: cl-error-handling @ SU-AI, DLW @ SCRC-STONY-BROOK
In-reply-to: Msg of 16 Oct 1984 17:12:18 EDT from Jim.Large at cmu-cs-spice.arpa

    Date: Tuesday, 16 October 1984 17:12:18 EDT
    From: Jim.Large at cmu-cs-spice.arpa

       It might be easier to distinguish an "error" from the broader class of 
    "conditions" by looking only at the point where the error is signalled.

       Perhaps an "error" is a condition signalled by some routine when
    that routine has been given inconsistent inputs (its contract has been
    violated by its caller) and it does not know what else to do.

       By this definition, division-by-zero is an error because it is the 
    condition raised by the divide instruction when divide is given illegal
    operands.

I believe the point Dan was trying to raise was the more subtle one that
functions may signal an error when they get inconsistent inputs is fine,
but to say they must signal an error when they get inconsistent inputs is
in fact contradictory. It is the same as saying that the program is defined
to work in a certain way when it is not defined to work. It's a messy
point. My intuition is that we should avoid any definition of error which
refers to the program's contract.

I spoke with Albert Meyer about this problem and he said the theory of
computation people don't have any agreement on the issue either. His advice
was just to muddle through it as best we could.

How about if we modified the definition to simply say that if a given 
lexical contour signals an "error" (as contrasted with a "condition") 
then it cannot be proceeded without externally provided advice about how to
proceed (ie, handling of some sort). People will typically use such a 
facility to deal in ways that relate to contract violation, but that will 
just be a point of style, not a point of definition.
-kmp

∂16-Oct-84  1630	HANDERSON@CMU-CS-C.ARPA  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  16:29:57 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 16 Oct 84 19:28:22-EDT
Date: Tue, 16 Oct 1984  19:28 EDT
Message-ID: <HANDERSON.12055996789.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@MIT-MC.ARPA>
Cc:   cl-error-handling@SU-AI.ARPA
In-reply-to: Msg of 13 Oct 1984  19:24-EDT from Kent M Pitman <KMP at MIT-MC>


Actually, I disagree with the terminology.  "Event" is fine.  However, you're
presuming that there will be a "condition object" associated with a particular
event, and I think there may be some other issues we need to get through first.
I think condition should be reserved to mean "an event deemed interesting by
CL".  That way, we can talk about whether an event is a condition or not.  I
also think less-common word should be used for the things that may eventually
be created - perhaps the phrase "condition object" or somesuch (we don't need
to agree what this is yet).  One would then signal conditions, not events.

A letter I will try to write later this evening will talk about error and some
other related issues.  It will probably also lead the discussion further, so
messages realting to terminology should probably try to reach a conclusion.
Moon has flamed at me for reserving nice words for flavor stuff - I think nice
words should only refer to non-implementation things.

-- Steve

∂16-Oct-84  1712	KMP@MIT-MC 	more on terminology    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  17:12:37 PDT
Date: 16 October 1984 20:15-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  more on terminology
To: Handerson @ CMU-CS-C
cc: cl-error-handling @ SU-AI
In-reply-to: Msg of Tue 16 Oct 1984  19:28 EDT from Steven <Handerson at CMU-CS-C.ARPA>

    Date: Tue, 16 Oct 1984  19:28 EDT
    From: Steven <Handerson at CMU-CS-C.ARPA>

    Actually, I disagree with the terminology.  "Event" is fine.
    However, you're presuming that there will be a "condition object"
    associated with a particular event, and I think there may be some
    other issues we need to get through first.  I think condition should
    be reserved to mean "an event deemed interesting by CL".  That way,
    we can talk about whether an event is a condition or not.  I also
    think less-common word should be used for the things that may
    eventually be created - perhaps the phrase "condition object" or
    somesuch (we don't need to agree what this is yet).  One would then
    signal conditions, not events...

Actually, I don't think we disagree on this. This is certainly a
restatement of what I intended to say. If it makes it clearer to
rephrase it this way, I'm happy.

The reason I had proposed eliminating the word "event" was that I
thought it presupposed the existence of objects representing conditions
and I wanted to avoid terminology that forced an object-oriented view of
error handling. Indeed, I think that "condition" is a fine name for what
the LispM documentation calls "events" and I agree that if we ever adopt
an object-oriented view, we should call the objects which represent
conditions "condition objects".

The word "event" is too generic to lock down for any use even so specific
as condition raising, which is another reason I wanted to free it. I don't
think it is fair to assign it technical meaning.
-kmp

∂16-Oct-84  1814	HANDERSON@CMU-CS-C.ARPA 	more on terminology 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  18:14:39 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 16 Oct 84 21:12:53-EDT
Date: Tue, 16 Oct 1984  21:12 EDT
Message-ID: <HANDERSON.12056015810.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@MIT-MC.ARPA>
Cc:   cl-error-handling@SU-AI.ARPA
Subject: more on terminology
In-reply-to: Msg of 16 Oct 1984  20:15-EDT from Kent M Pitman <KMP at MIT-MC>


No, I don't see event being used for much else.  We do need something to
replace it if we do, because otherwise condition would have two meanings.  
Why don't we just capitalize everything and be done with it?

-- Steve

∂16-Oct-84  1958	HANDERSON@CMU-CS-C.ARPA 	Error-ology    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Oct 84  19:58:02 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 16 Oct 84 22:56:10-EDT
Date: Tue, 16 Oct 1984  22:56 EDT
Message-ID: <HANDERSON.12056034618.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   "Daniel L. Weinreb" <DLW@SCRC-STONY-BROOK.ARPA>
Cc:   cl-error-handling@SU-AI.ARPA, KMP@MIT-MC.ARPA
Subject: Error-ology


Your letter seems to suggest this: Whether a condition (event) is @i(errorful)
depends upon the particular code being executed, as well as the lexical and
dynamic environment.  I think this is all we really need to say.  A program
being @i(in error) is a different thing entirely, although it is likely that
one grossly in error will eventually come to an errorful event.

Actually, I guess there is more.  One way a program can be in error is not to
handle a given condition.  If conditions are globally named and dynamically
scoped, a handler for a condition in one program segment may inadvertantly
handle the same condition in another segment.  The solution to this - some
means of explicitly manipulating the conditions associated with a function -
would probably lead to a better condition system, but it might also lead to
some language other than CL.  I still think it would be a mistake to not think
about this.

The set of conditions an implementation (or CL) has is chosen on the basis of
what events will cause unpredictable or inconsistent (in the sense of math, the
CL manual, etc) results.  The condition handling mechanism provides a way that
programs can recover from such events by providing their own interpretation of
what to do next.  For instance, short-floats do not overflow into long floats
because of the change in precision; some application may decide to remember the
precision itself, ignore the precision, etc.  I doubt many handlers will be
comlpicated, but if so, it would be nice if handlers could be filed away (for
instance, were normal functions).

Also, the distinction between an error's occurrence and detection is an
important one.  In general, you can't detect an error itself (except through
varying degrees of code analysis), only some errorful consequence.  This may
actually be important if we have to talk about (asynchronous?) errors in "jobs"
given to slave processes - the "error" might be in the master.

-- Steve

∂17-Oct-84  1127	FONTANA%ti-csl.csnet@csnet-relay.arpa 	Terminology of error-ology
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  11:27:22 PDT
Received: from ti-csl by csnet-relay.csnet id a000485; 17 Oct 84 12:55 EDT
Date: 17 Oct 1984 1144-CDT
From: Mary <Fontana@TI-CSL>
Subject: Terminology of error-ology
To: cl-error-handling@SU-AI
Received: from csl60 by ti-csl; Wed, 17 Oct 84 11:50 CST



I think a condition should be an event or some exceptional situation
detected in your program.  An error is a condition which when
signalled will be handled by an interactive debugger (error handler)
if no other handler handles it first.  A program can signal a
condition or an error and define its own handlers.  An error always
has at least one handler - the error handler, which invokes an
interactive debugger. 


-- Mary Fontana

  Fontana@ti-csl
-------

∂17-Oct-84  1529	HANDERSON@CMU-CS-C.ARPA 	Terminology of error-ology    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  15:29:37 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 17 Oct 84 18:25:59-EDT
Date: Wed, 17 Oct 1984  18:25 EDT
Message-ID: <HANDERSON.12056247570.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Mary <Fontana.Ti-Csl@CSNET-RELAY.ARPA>
Cc:   cl-error-handling@SU-AI.ARPA
Subject: Terminology of error-ology
In-reply-to: Msg of 17 Oct 1984  12:44-EDT from Mary <Fontana at TI-CSL>


Yeah, that's what I was thinking, but I don't think it's particularly valuable
to define an error that way.  Error can and should be thought of in many
contexts, and I don't think "condition with a debugger handler" needs a new
name - I think "errorful condition" is enough.  Condition can too, but I think
it's only other major meaning is Event.

Just to be argumentative, I don't think you need every condition to have a
handler - for some applications, the debugger may be inappropriate.  Perhaps as
a matter of style you do, and obviously you don't want the "no handler"
condition to have no handler.

-- Steve

∂17-Oct-84  2222	Moon@SCRC-QUABBIN.ARPA 	Proposed agenda 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  22:21:52 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 92350; Thu 18-Oct-84 01:21:12-EDT
Date: Thu, 18 Oct 84 01:21 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Proposed agenda
To: CL-error-handling@SU-AI.ARPA
Message-ID: <841018012150.2.MOON@EUPHRATES.SCRC.Symbolics>

Here is a list I made some years ago of issues that ought to be addressed
by the Common Lisp "error-handling system".  I have updated the list
somewhat from what I wrote back then, in case anybody has seen it before.
Perhaps this will be helpful in focussing the discussion on something more
concrete than terminology.


Recognize that we want to deal in ERRORS (events that prevent the program
that detected the event from continuing to execute without intervention),
NON-ERROR CONDITIONS (events that can safely be ignored), and DEBUGGER
CONDITIONS (events that prevent the program that detected the event from
continuing to execute without intervention, but ought not to be intercepted
by "catch all errors" mechanisms).

Provide names for unusual conditions (including but not limited to errors)
and a taxonomic system for classifying those names.  A name can be defined
to include one or more other names; this inclusion relation is transitive.
For example, division-by-zero includes arithmetic-error; no-such-version
includes file-not-found, which in turn includes file-error.  All of the
above include error, a very general condition name.  If X includes Y, then
X is a more specialized version of Y.  This taxonomic system makes it
possible to handle generic classes of errors, as well as specific errors.

Add SIGNAL, which is like WARN but doesn't print anything if the condition
is not an error and not a debugger condition.

Extend ERROR, CERROR, WARN, SIGNAL, and BREAK to permit signalling conditions
by name.  (Perhaps also extend CHECK-TYPE and ASSERT the same way).  If
a symbol appears where the current syntax calls for a format-string argument,
the symbol is the name of the condition.  The interpretation of the remaining
arguments after the symbol depends on the particular condition.  A common
technique is to take the next argument after the symbol to be a format string
and the remaining arguments to be arguments to that format string.  Another
common technique is for the condition name to imply the format string and
for the remaining arguments to be &key arguments that specify various relevant
quantities.  Since any program that signals a condition must necessarily
understand the meaning of that condition, there is no need to enforce a
uniform protocol on these arguments, just as there is no need for all functions
to take exactly the same arguments.

Ways to establish condition handlers, so that programs may respond to
conditions, by throwing out, by continuing, or by correcting the reason for
the condition and retrying.  We have developed a number of special forms
that are convenient to use in this context; the most useful subset includes
CONDITION-BIND, CONDITION-CASE, IGNORE-ERRORS, and CATCH-ERROR-RESTART,
although there are several others that may or may not be worthwhile.

Ways to define the behavior and relationships of conditions.  This
presumably involves a DEFINE-CONDITION special form that defines the name
of the condition, the names of the conditions that it includes, the
arguments to be supplied when signalling the condition, documentation, and
control over how the condition prints its error message and how it can be
recovered from.

Define the protocol by which a condition handler can obtain the arguments
that were supplied when the condition was signalled, can determine what
ways of recovering from the condition are available and invoke one of them,
and can choose either to supply values needed for recovery or to let the
condition system prompt the user interactively for the values.  This
involves a three-way handshake between the program that signalled the
condition, the program that handled the condition, and the condition
definition (which acts as the interface between the other two).  We have
developed the concept of "proceeding" and "proceed types" for this purpose.

Ways to use conditions as inter-module interfaces.

Ways to use conditions to customize the behavior of the interactive
debugger.  Ways to use condition handlers to write new interactive
debuggers for specialized applications.

--- other related issues ---

Formalization of the notion of "aborting a program," and provision of
mechanisms to define where control will be thrown to when the program is
aborted, as well as a function to abort the program.  This is more
complex than it seems because of interaction with the interactive
debugger and the condition system.

Standardization of conditions signalled by the system for various "signals
an error" cases.  Standardization of conditions signalled by those
implementations that do signal errors in various "is an error" cases.
Portable floating-point exception, overflow, and rounding control, with
some provision for different levels of implementation of the standard by
different systems, depending on their hardware.

Facilities making it possible for a user to write a portable debugger.
This is a major project.

A way to define the default description string for a user-defined type,
used when CHECK-TYPE is called with only two subforms.  This can of
course be a function of the type's parameters when the type is not
simply a symbol.

∂19-Oct-84  0048	HANDERSON@CMU-CS-C.ARPA 	Proposed agenda
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Oct 84  00:47:49 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Fri 19 Oct 84 03:42:45-EDT
Date: Fri, 19 Oct 1984  03:42 EDT
Message-ID: <HANDERSON.12056611081.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Cc:   CL-error-handling@SU-AI.ARPA
Subject: Proposed agenda
In-reply-to: Msg of 18 Oct 1984  01:21-EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>


I agree that there needs to be some taxonomic error handling system.  Catching
all errors just means catching all conditions that are more specific conditions
than the ERROR condition.  However, I disagree with your statement that there
is something fundamentally different about error conditions besides their
handlers.  I think Mary Fontana agrees with me here.  Is there anyone else out
there?  Hello?

I also disagree with the idea that we have to interface to ERROR, CERROR, etc.
The whole point of signal is that the handler gets to decide whether to halt
execution, invoke the debugger, etc.  Indeed, a handler might use ERROR or
CERROR as a result of it's operation.  If you KNOW at the point of error that
you can't proceed, you use ERROR to tell the user why.  The only reason ERROR
would want to signal a condition is if the act of signalling computed some
other information, which sounds more like a case for modular programming than
error handling.  If all else fails, you can always write a function FOOME-ERROR
that performs the relevant computation and calls ERROR.

I am entirely grossed out by the thought of using conditions as inter-module
interfaces.  Obviously, it is PART of the interface, in the same way that
function names, function arguments, and specials are, but none makes up an
entire interface.

CONDITION-BIND and -CASE sound ok, I suppose.  IGNORE-ERRORS and maybe even
CATCH-ERROR-RESTART sound like they should be implemented in terms of something
else.  "Proceed types" and argument protocol are going to be the biggies.

-- Steve

∂24-Oct-84  0236	HANDERSON@CMU-CS-C.ARPA 	Start of a proposal 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Oct 84  02:36:44 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 24 Oct 84 05:36:38-EDT
Date: Wed, 24 Oct 1984  05:36 EDT
Message-ID: <HANDERSON.12057942529.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Steven <Handerson@CMU-CS-C.ARPA>
Cc:   CL-error-handling@SU-AI.ARPA
Subject: Start of a proposal
In-reply-to: Msg of 19 Oct 1984  03:42-EDT from Steven <Handerson>


Here is a collection of some of my own (recent) ideas on how things should
work.  I thought I'd see if anyone has any reactions or suggestions based on
what I can throw together.  I haven't thought at all about compatibility or the
more esoteric aspects, just simplicity.  

I haven't thought about proceeding much, but the bit about whether to prompt or
not sounds bogus.  Why not just have different proceed types, some that prompt
that the debugger uses, and some that don't for normal handlers?  The first can
call the second.  I do think that proceed types deserve some special mechanism.

----

I basically agree with the idea that signalling a condition makes an explicit
condition object of some form, and that handling a condition consists of
performing operations on this object.  Proceed types are a kind of operation.
Condition objects naturally have some internal state (if nothing else, the
arguments to signal), which I will call instance variables, not to be confused
with those found in Flavors.

I propose that we not get into the idea of "combining" operations, since that's
messy.  I propose the only rule we adopt is that operations of more specific
conditions shadow the more general ones.  I propose that an error be signalled
when there are two candidates for inheritance (as in A and B have operations
:foo, and C is a kind of A and a kind of B); usually the desired operation is a
hybrid, and having the system pick one is just one more pointless thing to
remember and abuse.  [Operations will be normal functions, in which case you
would be able to stick the same one two different places easily.]  Operations
can still interact by calling eachother.

A condition has some required and some optional arguments, some of which may be
inherited from more general conditions.  In addition, some more specific
conditions may be able to construct the more general arguments, so that
arguments previously required are now optional, or what were supplied are now
computed.  In fact, computed arguments are indistinguishable in function from
values cached in instance variables.  I propose that rather than trying to
untangle these things, we just use a disembodied property list as the
internal state.  If the arguments to signal are just paired argument name -
value, all we need to do to get the condition object is make it a list.
A cursory investigation has shoen other approaches to be either complicated or
gross. 

Of course, this does need some discipline.  I think that all that really needs
to be done is to help the user figure out what's required and what's optional.
This can be accomplished with describe and by warning at compile time about
either missing required arguments or unknown arguments.  Also, if Flavors users
can keep from tripping over other instance variables, then there shouldn't be
much problem with condition instance variable conflicts.

Something that would be nice would be a standard (automatic) way of specifying
how various optional instance variables are calculated from the supplied ones.
A simple mechanism would be to have the iv-referencing primitive send the
condition a message [the variable name] if it isn't in the plist.  A more
specific condition that no longer requires some argument simply provides an
operation that can calculate it.

∂27-Oct-84  2150	RPG  	Hello folks   
To:   cl-error-handling@SU-AI.ARPA    

We now have a chairman of the error handling subgroup:  Kent Pitman of
MIT. I think he will make an excellent chairman.  For your information I
am including the current members of the mailing list.

I will now let Kent Pitman take over responsibility for the discussion.

Dave Matthews		HP		"hpfclp!errors%hplabs"@csnet-relay
John Foderaro		Berkeley	jkf@ucbmike.arpa
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay
Kent Pitman		MIT		kmp@mc
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Jim Large		PERQ		Jim.Large@cmu-cs-spice
Mary Fontana		TI		fontana.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-errors@mc
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Alice Hartley		BBN		hartley@bbn
David Moon		Symbolics	moon@scrc-stonybrook
Eric Benson		Lucid		eb@su-ai
Dan Weinreb		Symbolics	DLW@scrc-stonybrook
Steve Handerson		CMU		handerson@cmuc
Jim Larus		Berkeley	larus@berkeley
Neal Feinberg		Symbolics	feinberg@scrc-stony-brook

∂30-Oct-84  1911	HANDERSON@CMU-CS-C.ARPA 	More about proposal 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Oct 84  19:11:43 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 30 Oct 84 22:11:32-EST
Date: Tue, 30 Oct 1984  22:11 EST
Message-ID: <HANDERSON.12059707416.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-error-handling@SU-AI.ARPA
Subject: More about proposal
In-reply-to: Msg of 28 Oct 1984  00:50-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


I've been reading the Symbolics documentation and thinking about proceed types.
The criteria a proceed type may use to determine whether it can proceed or not
may not be simple.  I haven't the experience to give an example, but the idea
of passing a list of the usable proceed types sounds forced.  Ideally, a
proceed type should be able to decide itself, based on the condition object and
any other environmental information it can determine.  [It can look for itself
in a supplied list of proceed types, if it wants.]

I propose a notion of an operation @i(failing), which can basically be
implemented as the operation's function returning some special value.  If an
operation fails unexpectedly, it's a bug, and the system invokes ERROR.  If the
operation was invoked using a special catching form, the handler can cause an
expression to be evaluated instead.

Does anyone have any comments whatsoever on my proposal so far?  If you think
it's too simple, we're only in the error-handling business, not programming in
general.  I agree it's slightly messy as stated, but a little attention might
smooth out the rough edges.  The slowest part in relation to a Flavors
implementation will be the assoc list of instance variables, and I don't
anticipate enough of them to make much of a difference.

-- Steve

∂17-Nov-84  1818	HANDERSON@CMU-CS-C.ARPA 	Proposal someday soon?   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Nov 84  18:17:50 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 17 Nov 84 21:17:24-EST
Date: Sat, 17 Nov 1984  21:17 EST
Message-ID: <HANDERSON.12064416171.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-error-handling@SU-AI.ARPA
Subject: Proposal someday soon?
In-reply-to: Msg of 30 Oct 1984  22:11-EST from Steven <Handerson>


I've had a few additional thoughts (starting with EXCEPTION HANDLING) since my
last series of posts, which seem to be leading up to a proposal.  I've had a
few important thoughts, so I'll give those to you now.  Any questions or
comments would be appreciated.

When I'm defining a term, I use italics (just like textbooks).  I quote
"cutesy" terms.  This also contains one or two humorous analogies.  

QUESTION:

Is there any reason to have an explicit condition object to pass around?
If you can hide this from the user, you need not fear reusing storage
(of course, that presupposes a uniform representation...).  

SUMMARY

I'm presuming a lot by taking these to be the current sway of the group.

The error system should probably be as powerful as we can reasonably make it.
It has been suggested that all you really need might be something like binding
a special; if so, you can easily do this yourself.  The condition system is for
hairier cases.  Various forms of language extensions (such as making objects
that masquerade as a new type) are also better dealt with using some other
mechanism, to prevent interactions with "normal" conditions.

We define our condition system to only handle synchronous events.  Presumably
an errorful condition resulting from a (more abstract) event will be signalled
dynamically inside the call that lead to it (and presumably knows how to handle
it).  If not, perhaps binding a more complicated handler earlier can deduce
from the environment which event has occurred.  It is the purpose of the
condition system to determine what abstract event has occurred and to invoke
the appropriate corrective code.

We want taxonomic error handling, as described by Moon.  This is actually where
most of the complexity comes from.  If all the conditions have arguments, then
we need some way of converting the arguments of a specific condition into those
of a more general one.  This is the crux of my proposal - I think some sort of
object-system fits in well, but it should be simple and specific enough so that
nobody feels left out, or pained to implement something huge (my proposal
will be almost entirely portable code, except for the implementation-dependent
signalling of system errors).

EXCEPTION HANDLING

The whole point of exception handling in most languages is to make the normal
cases go fast by simplifying the initial tests for exceptions.  If some simple
test as part of the calculation can prove that there is no error, you get error
checking practically for free.  Hence the idea that an errorful event is
detected via some errorful consequence.  The majority of these initial tests
are things that concern the language's integrity, and so should be dealt with
anyway; things like taking the car of 3 [I think these should be called
@i(system errors)].

ABSTRACTION

An event can often be viewed at several different levels of abstraction.  The
lowest is at the system error that caused its detection.  This can be
characterized in different ways, using the inclusion relation.  However, if one
uses implication (which depends upon the code), you're dealing with different
levels of abstraction.

Example:
"What's that?"
"It's condition SYS:DIVIDE-BY-ZERO."
"What's that?"
"An arithmetic error."
"What does that mean?"
(looks at code) "Well, here it means the user's input is inconsistent."

Revelation!  Handlers don't just handle errors; they actually determine (by
"looking at the code" whether a given (abstract) event has occurred.  This is
probably why handlers want to abstain; they figure out that the abstract
condition they handle hasn't occurred.  Defining errors inline would probably
be pretty clumsy; such things can be as complicated as the code.  Instead, I
think that we should investigate what it means to have a handler signal another
(more abstract) condition, which can be done in existing systems (and probably
is, occasionally).

Looked at this way, the purpose of the condition system is to determine the
appropriate abstraction of the event and @b(then) the action to be taken.
Hence it's reasonable to do things like (ERROR 'my-condition), because the
sequence of handlers can determine things about the error that might be useful
to the user.  Still, I think we need to be careful with exactly what these
forms do.

For example, I think it's quite possible that you'd want to signal a condition
IN CASE it's handled (at some level of abstraction).  System errors of course
can't be @i(continued) in the CL manual sense, but this could be what ERROR is
for.  Hence, @i(errors) (conditions signalled with ERROR) are proceedable, but
not continuable.  Errors signalled with CERROR are continuable and proceedable.

THE DEBUGGER

The debugger is a special beast, because the user is a special beast.  It
should be able to access all abstractions of the signal chain.  I think how
this is to be done is pretty (error-system-) implementation dependent, but the
basic idea is that you can go down into the stack and say "what are the proceed
options for this level?"  The portable code could have some hook for this.

The debugger complicates the notion of proceed types slightly.  Ideally, it
should know which proceed types it can invoke (and ask the user rather than
insisting it be in the arguments).  This changes with whether the handler was
invoked with ERROR, whether the proceed type returns from the signal form or
not, the signalled arguments, etc.  These aren't really general problems, and
my proposal will suggest one way of dealing with them.

I've also considered something that might be analogous to Symbolic's @i(special
commands).  These are like proceed types, but they're just designed to give the
debugger user more information about the error.  The more of this that gets
standardized, the better, but some implementation might want to expand on them.
The worst that can happen is that they not be used in portable code.  Again,
somebody might have better ideas of how to provide this kind of thing.

HANDLERS

The next paragraph assumes you know about the Symbolics implementation of
handler binding.  Basically there are several binding lists, which store pairs
of a handler function and the condition it's bound to.  When an error is
signalled, the lists are cdr'ed down in order until a handler binding of the
signalled condition or a condition that includes it is encountered.  Normal
bindings are consulted first, then default bindings (implementing "bind unless
condition already handled"), then "restart handlers" (self-descriptive), and
some fourth thing I forgot about.

I think there should be two kinds of handlers: the kind that handle and the
kind that deduce a more abstract event.  Restart handlers and such would be
normal handlers of some abstract and serious condition, like
EDITOR:USER-INPUT-GARBAGED.  This works fine if you change levels of
abstraction only after all handlers [all handlers that should, anyway] have a
crack at the current level .  Thus, in addition to the normal and default
bindings, there should be an "abstraction handler" binding list which gets
looked at after the other two.  Realize that "abstraction handlers" may be on
the normal binding list, for instance if a code segment doesn't want the
original error to escape to surrounding code.  Basically, if a piece of code
expects an error, it should bind a handler as close to the source as possible
that, if nothing else, signals a condition that better describes the event.

I suggest that people not worry too much about reaching inside other people's
code; designing good interfaces and clean code is generally more of a win.  If
you can make wine out of water, fine, but hacks only lead to more hacks (don't
give ME a bottle of water to get drunk on).  No, I don't think handlers should
be examining the stack (except the debugger, but that's special).

The whole process of selecting a handler is marginally complex.  A handler
selected for the originally signalled condition may be an "abstraction
handler", in which case it signals another condition.  If this returns nil,
then it hasn't been handled, and the handler probably returns nil itself,
allowing some other abstraction a chance.  Otherwise, it's up to the handler to
arrange that proceeding the new handler does the appropriate thing with the
previous condition object.

ALMOST EXAMPLE

If you were implementing an interpreter for some other (lispy) language in
Common Lisp, you'd want to map events in Common Lisp into those in the new
language.  Handlers for system errors would push the interpretation level, and
signal some new-language condition, depending upon what was being interpreted
and the lisp system error signalled.  If the interpreter functions were
quantized, there would be no reason to proceed a lisp error; the handlers could
just restart the current new-language primitive (perhaps by throwing to a catch
around all the primitives functions).  In fact, the proceed types of the
new-language condition objects could do this directly, and the lisp handler
would just notice the abstraction.  Unexpected errors would not get abstracted
(presuming you bound the abstraction handler close enough to the source), and
would cause the interpreter to bomb out.

Other examples?

∂07-Feb-85  1612	FONTANA%ti-csl.csnet@csnet-relay.arpa 	New year error handling   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 7 Feb 85  16:12:07 PST
Received: from ti-csl by csnet-relay.csnet id aa01387; 7 Feb 85 18:59 EST
Date:  7 Feb 1985 1634-CST
From: Mary <Fontana%ti-csl.csnet@csnet-relay.arpa>
Subject: New year error handling
To: cl-error-handling@su-ai.ARPA
Received: from csl60 by ti-csl; Thu, 7 Feb 85 17:00 CST

I haven't seen anything from this committee since last year in October.
Have we resolved any of the following?

Definition of a condition and an error:
 - A CONDITION refers to "something that happens" during the
execution of a program.
 - An ERROR is a particular type of condition which is
associated with an event that has been detected by a program
as not part of its contract. When an error condition is
signalled, the program may not proceed without the condition
having been handled somehow. This implication is not
necessarily true of all conditions-- only of error conditions.
 - A CONDITION OBJECT represents a condition.  Holds
information about the particular condition, such as the message
describing the error, ways to proceed, data used by the
condition handler, ...

Creating a condition
  Like, MAKE-CONDITION or DEFSIGNAL

Signalling a condition.
  SIGNAL, ERROR, CERROR, .... (allow an argument for a condition name).

Establishing a handler.
   IGNORE-ERRORS, CATCH-ERROR, CONDITION-BIND, CONDITION-CASE,
CONDITION-CALL.  

What about resume handlers?  
Establish resume handlers with ERROR-RESTART, ERROR-RESTART-LOOP, 
CATCH-ERROR-RESTART, or CATCH-ERROR-RESTART-EXPLICIT-IF.

Proceeding & Proceed Types?
  Defined when create the condition object.  Also, CERROR and SIGNAL
provide ways to specify proceed types.  Rusume Handlers define proceed
types. (I didn't follow what Steve was proposing here last year).
  
What is the signalling mechanism?
  I'm assuming that functions, such as ERROR and SIGNAL, will "signal
a given condition" which means the system  first searches a list of
condition handlers for a previously established handler associated
with this condition.  If one is found invoke it,  otherwise (possibly)
invoke the Debugger. And finally look down a list of resume handlers.

-------

∂07-Feb-85  1646	KMP@SCRC-QUABBIN.ARPA 	New year error handling    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Feb 85  16:45:52 PST
Received: from CHAGRIN by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 131429; Thu 7-Feb-85 19:45:56-EST
Date: Thu, 7 Feb 85 19:47 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: New year error handling
To: Fontana%ti-csl.csnet@CSNET-RELAY.ARPA
cc: cl-error-handling@SU-AI.ARPA
In-Reply-To: The message of 7 Feb 85 17:34-EST from Mary <Fontana%ti-csl.csnet@csnet-relay.arpa>
Message-ID: <850207194706.3.KMP@CHAGRIN.SCRC.Symbolics.COM>

    Date: 7 Feb 1985 1634-CST
    From: Mary <Fontana%ti-csl.csnet@csnet-relay.arpa>

    I haven't seen anything from this committee since last year in October.
    Have we resolved any of the following? ...

Yes, nothing has been sent recently. As you will recall, the discussion was
not going anywhere because we were
      (a) going in circles on terminology 
 and  (b) speaking at too detailed a level. Handerson's "proposals" were the
          sort of thing that really belonged on CL-OBJECT-ORIENTED-PROGRAMMING,
          where he finally diverted his interest.
In fact, I also wanted to wait a little and see what the object people came 
up with, but that discussion is not moving very quickly either.

So, trying to figure out how to salvage this design effort, I went back to
the drawing board and worked out a complete proposal (and implemented it 
in Maclisp to see how it feels -- which was pretty good). I think it will
serve as a reasonable basis of discussion. I've been changing jobs over the
last two weeks, so have been slow in getting it out to the list, but I'll
up its priority and try to get it on the record for you all to look at sometime
within the next day or so.
-kmp

∂08-Feb-85  0032	KMP@SCRC-STONY-BROOK.ARPA 	Stripped down version of LispM error system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Feb 85  00:32:25 PST
Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 174758; Fri 8-Feb-85 03:36:57-EST
Date: Fri, 8 Feb 85 03:33 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Stripped down version of LispM error system
To: CL-ERROR-HANDLING@SU-AI.ARPA
In-Reply-To: <850207194706.3.KMP@CHAGRIN.SCRC.Symbolics.COM>,
             The message of 7 Feb 85 17:34-EST from Mary <Fontana%ti-csl.csnet@csnet-relay.arpa>
Message-ID: <850208033355.8.KMP@CHAGRIN.SCRC.Symbolics.COM>

The following proposal amounts to a stripped down version of what the
LispM provides. Most of the stripping down has to do with hiding
the fact that the LispM had flavors to play with and I didn't want
to depend on that.

I have an implementation of this for Maclisp. I'll see about working
out a CL implementation from that. I don't think it will be hard.

If any parts of this seem vague, let me know and I can elaborate. 
This message covers really only technical details. I have given a lot
of thought on how to describe this conceptually and will do so under
separate cover at a later date.

Anyway, maybe this will give everyone something concrete to center the
discussion around.
-kmp

!

(SIGNAL condition-type key1 val1 key2 val2 ...)		Function

  Signals a condition of the given CONDITION-TYPE with attributes
  given in keyed format. (Note: the keys are not keywords, but 
  packaged symbols.)

  If the signal is not handled, then some default action will be
  taken. The default for ERROR and conditions built on ERROR is 
  to enter the debugger. The default for other conditions is to 
  return NIL.

  Example:

	(SIGNAL 'BAD-FOOD-COLOR
		'FOOD  'MILK
		'COLOR 'GREENISH-BLUE)

	This signals a BAD-FOOD-COLOR condition, providing information
	to the condition that the FOOD was MILK and the COLOR was
	GREENISH-BLUE.

!

(SIGNAL-CASE (condition-type
	      key1 key-value1
	      key2 key-value2
	      ...)
  ((proceed-type-1 . bvl1) . body1)
  ((proceed-type-2 . bvl2) . body2)
  ...)							Special Form

  Signals a condition of the given CONDITION-TYPE with attributes
  as given by the KEYs and KEY-VALUEs. The CONDITION-TYPE and KEYs
  are not evaluated, but the KEY-VALUEs are.

  If the condition is not handled, the default action is according to 
  the rules for the simple case of SIGNAL.

  If the condition is handled, it may be proceeded by calling a proceed
  function which has the name of a PROCEED-TYPE given in the body of the
  SIGNAL-CASE. (The only valid names for PROCEED-TYPEs are those 
  that have been defined using DEFINE-PROCEED-TYPE.) If a proceed function
  is called, the BODY of its corresponding in the SIGNAL-CASE is executed
  with the variables in its BVL bound to the arguments given the proceed
  function, and the return value of that BODY becomes the return value of
  the SIGNAL-CASE.

  Example:

	(LET ((MY-FOOD       'MILK)
	      (MY-FOOD-COLOR 'GREENISH-BLUE))
	  (DO ()
	      ((REASONABLE-COLOR-FOR-FOODP FOOD COLOR))
	    (SIGNAL-CASE (BAD-FOOD-COLOR
			  FOOD  MY-FOOD
			  COLOR MY-FOOD-COLOR)
	      ((USE-COLOR NEW-COLOR) (SETQ MY-FOOD-COLOR NEW-COLOR))
	      ((USE-FOOD  NEW-FOOD)  (SETQ MY-FOOD       NEW-FOOD))))
	  (LIST MY-FOOD MY-FOOD-COLOR))

	This signals a BAD-FOOD-COLOR condition, specifying that FOOD 
	was MY-FOOD and COLOR was MY-FOOD-COLOR. If the caller wants 
	to proceed the condition, he may do something like:

		(USE-COLOR condition 'WHITE)
	     or (USE-FOOD  condition 'CHEESE)

	In this case, the return value of the SIGNAL-CASE is 
	ignored because both handlers work by side-effect.

!

(CONDITION-BIND ((condition-name1 handler1)
		 (condition-name2 handler2)
		 ...)
  . body)						Special Form

  When a condition is signalled, handlers are searched for in the dynamic
  environment of the signal. Handlers can be established by use of
  CONDITION-BIND.

  Handlers are functions of one argument (an object representing the
  data associated with the condition). They may wish to first inspect 
  the object using one of the following primitives:

	(CONDITION-SLOT condition slot-name)

	  Reads a named slot in the given condition.

	(CONDITION-PROCEED-TYPES condition)

	  Returns a list of the valid proceed types for the 
	  given condition.

  After inspecting the condition, the handler must take one of 
  the following kinds of actions:

  It may decline to handle the condition, by executing: 
	(DECLINE condition)
    The effect of this will be as if the handler had been invisible to the
    mechanism seeking to find a handler. The next handler in line will be
    tried, or if no such handler, the default action for the given 
    condition will be taken.

  It may perform some non-local transfer of control. For example,
     . It can throw to a tag.
     . It may signal an error (which will force implicit transfer
       of control).
     . It may call the function (ABORT) to unwind back to toplevel
       or the innermost (CATCH-ABORT ...) form.

  It may proceed the condition, using
	(proceed-type condition . values)
     For example, if the signal was done via
	(SIGNAL-CASE (FOO-ERROR)
          ((USE-VALUE X) (* X X)))
     and the handler does
	(USE-VALUE condition 7)
     then the SIGNAL expression will return 49.

     There is also a function (INTERACTIVE-PROCEED condition) which will
     prompt the user for a selection of how to proceed by inspecting
     the condition to see what proceed options are available. This is
     primarily useful in implementing the debugger, but may have other
     applications from time to time.

  The debugger may be entered, by invoking:
     (INTERACTIVE-DEBUGGER condition)

!

(DEFINE-SIMPLE-CONDITION name slots parents
  . report-method)					Special Form

  NAME is the name of the new condition to be defined.

  PARENTS is a (possibly null) list of condition types that the
  new condition types is to inherit from.

  SLOTS is described by:	
	  slot-name ! (slot-name) ! (slot-name slot-default-value)
     If the SLOT-DEFAULT-VALUE is not given (as in the first two cases), 
     a value must be given for the slot at SIGNAL time. If a default is
     given, an initialization for the slot is optional at SIGNAL time.

  The REPORT-METHOD is a body of forms will be run in an environment 
  where variables are bound which have the names of the slot names for
  the condition being defined and its parents. The REPORT-METHOD should
  do typeout to the default output stream. It should have NO side-effects
  other than this typeout. Its return value will be discarded. If no
  REPORT-METHOD is specified, then the first condition in the parents
  list which (explicitly or implicitly) has a report method will be the
  error reporter for this condition.

  Example:

	(DEFINE-SIMPLE-CONDITION MACHINE-ERROR (MACHINE-NAME) (ERROR)
	  (FORMAT T "There is a problem with ~A." MACHINE-NAME))

	This defines a MACHINE-ERROR condition which inherits from ERROR.
	Initialization of MACHINE-NAME is required at SIGNAL time.

	(DEFINE-SIMPLE-CONDITION MACHINE-NOT-AVAILABLE () (MACHINE-ERROR)
	  (FORMAT T "The machine ~A is not available." MACHINE-NAME))

	This defines a new, more specific, condition for use when machines 
	are not available. Like MACHINE-ERROR, a value for the the 
	MACHINE-ERROR slot must be specified when the error is signaled.

	(DEFINE-SIMPLE-CONDITION MY-FAVORITE-MACHINE-NOT-AVAILABLE
				 ((MACHINE-NAME "MIT-MC.ARPA"))
	  (MACHINE-NOT-AVAILABLE))

	The required nature of the MACHINE-NAME slot is over-ridden here
	because the new condition type makes it optional (and gives it a
	default value). Since no REPORT-METHOD was given, however, the
	report method for MACHINE-NOT-AVAILABLE will be used if the
	condition is asked to report.

!

(DEFINE-PROCEED-TYPE name pretty-name
  (var1 exp1)
  (var2 exp2)
  ...)							Special Form

  Defines a proceed type, which may appear in a handler clause of a 
  SIGNAL-CASE. The PRETTY-NAME is for use in the debugger. eg, if 
  the debuggers sees this proceed type is a proceed option for a given
  condition, it will show its PRETTY-NAME. It should be a complete
  sentence but not uppercased (unless it starts with a word that is 
  always seen upcased) and not followed by a period. The VARs name 
  values that are needed by this proceed type. The EXPs should compute 
  or prompt for any relevant values (they will be used only 
  interactively). The debugger (or other tool) will upcase the first 
  letter and add a period if contextually appropriate.

  Example:

        (DEFINE-PROCEED-TYPE USE-FOOD  "use some other kind of food"
	  (FOOD  (PROMPT-AND-READ :STRING "What kind of food? ")))

        (DEFINE-PROCEED-TYPE USE-COLOR "use some other color"
	  (FOOD  (PROMPT-AND-READ :STRING "What color? ")))
	
  Using these definitions, a session with the debugger (from the
  food example above) might look like:

	...
	>>Error: The food MILK was found to have color GREENISH-BLUE.
	The following commands may be used to proceed:
	 meta-A:	Use some other kind of food.
	 meta-B:	Use some other color.
	 control-G:	Return to toplevel.
	DBG>meta-A
	What color? white
	...

  or perhaps, depending on the implementation, like:

	...
	The milk was greenish-blue. 
	  Use some other kind of food? (Y or N) No.
	  Use some other color? (Y or N) Yes.
	  What color? white
	...

!

(ABORT)							Function

  Returns control to "toplevel", which is defined as the innermost
  (CATCH-ABORT ...) expression. The outermost expression in any process
  will always have a (CATCH-ABORT ...) around it, return from which will
  either terminate or restart the process as appropriate to the
   application.
  
(CATCH-ABORT . forms)					Special Form

  Executes the forms in its body. If no (ABORT) is done, the value returned
  by the last of the forms will be the value returned by the CATCH-ABORT 
  form. If an (ABORT) is done, then NIL will be returned instead.

!

Notes:

 Which condition types will be initially defined. At the very least ERROR 
 should be.

 Which proceed types will be initially defined. I would argue that 
 something like 
	(DEFINE-PROCEED-TYPE USE-VALUE "use some other value"
	  (VALUE (PROMPT-AND-READ :EXPRESSION "Value to use: ")))
 is quite handy and might want to come pre-defined.

 What condition types are signaled by the already-defined error functions,
 such as ERROR and CERROR.

 This intentionally does not need flavors or any kind of fancy object
 system, though it could snap smoothly into such if
 CL-OBJECT-ORIENTED-PROGRAMMING finally comes up with one. I've implemented
 this for Maclisp, so I know it works.  eg, I've intentionally left aspects
 of the REPORT-METHOD for a condition vague enough that it does not require
 "instance variables" in any magic sense, by not defining what happens if
 you assign the variables.  Internally, just a LET that binds a bunch of
 variables to data structure accesses will work just fine.

 DEFINE-SIMPLE-CONDITION is not called DEFINE-CONDITION in case we 
 later want to make a hairier version that offers more than just a 
 REPORT-METHOD. Giving it this less-generic name will avoid possible
 naming confusion later.

 There may want to be some analogs of the LispM's CONDITION-CASE and other
 more "abstract" operations, but those are easily implementable once we get
 this much mechanism agreed upon, so I've left them out of this proposal.