perm filename CLERHA.MSG[COM,LSP]1 blob sn#772841 filedate 1984-10-30 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