[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Status: DRAFT


References: Condition System (Revision 18)

Category: ADDITION

Edit history: 26-Sep-88, Version 1 by Pitman

06-Oct-88, Version 2 by Pitman

09-Oct-88, Version 3 by Pitman

10-Mar-89, Version 4 by Pitman (remove unsupported options)

Problem Description:

The description of the Common Lisp condition system presupposes

only DEFSTRUCT and not DEFCLASS because it was written when

CLOS had not been adopted. It is stylistically out of step with

CLOS in a few places and places some restrictions which are not

necessary if CLOS can be presupposed.


1. Define that condition types are CLOS classes.

2. Define that condition objects are CLOS instances.

3. Functions such as SIGNAL, which take arguments of class names, are

permitted to take class objects. Such class objects must still be

subclasses of CONDITION.

4. Define that slots in condition objects are normal CLOS slots. Note

that WITH-SLOTS can be used to provide more convenient access to the

slots where slot accessors are undesirable.

5. Incompatibly change the syntax of a slot in DEFINE-CONDITION

to be compatible with a DEFCLASS slot specification.

An implication of this change is that forms like


would have to be written




6. Permit multiple parent-types to be named in the list of parent types.

Define that these parent types are treated the same as the superior

class list in a CLOS DEFCLASS expression.

7. Eliminate the :CONC-NAME option to DEFINE-CONDITION.

8. Define that condition reporting is mediated through the PRINT-OBJECT

method for the condition type (class) in question, with *PRINT-ESCAPE*

always being NIL. Specifying (:REPORT fn) in the definition of a

condition type C is equivalent to doing




These changes are consistent with the intent of the X3J13 endorsement

of CLOS and the Common Lisp Condition System.

Although items 5 and 7 are incompatible with the interim condition

handling which we've been working with, the overall proposal significantly

improves compatibility with CLOS.

This compatibility will make the language seem less fragmented, and

probably more learnable because there will be fewer paradigms to learn.

Also, items 5 and 7 in particular are an improvement for reasons

unrelated to CLOS if only because they get rid of the need for symbol

concatenation, a process which has been seen to cause problems because

of the transient nature of the binding of *PACKAGE*.


Slot specifiers...

A slot specifier of X is still valid but is incompatibly

changed to mean what CLOS has it mean; no :INITARG or

:READER would be supplied.

A slot specifier of (X) is still valid but is incompatibly

changed to mean what CLOS has it mean; no :INITARG or

:READER would be supplied.

A slot specifier of (X V) would no longer be valid.

In addition, other slot specifiers such as


are permitted as in DEFCLASS.

Conc names ...


would be rewritten




Report methods ...





(FORMAT STREAM "Oops! Something went wrong.")))


>>Error: Oops! Something went wrong.

Current Practice:

Some implementations supporting CLOS probably already do this,

or something very similar.

Cost to Implementors:

If you really have CLOS, this is very straightforward.

Cost to Users:

Small, but tractable.

The main potential problems are:

- :CONC-NAME. There is nothing that keeps an implementation from

continuing to support :CONC-NAME for a short while until old code

has been upgraded.

- The incompatible change to slot syntax. Again, it is possible to

unambiguously recognize a 2-list as old-style syntax and an

implementation can provide interim compatibility support during

a transition period.

Even if implementations did not provide the recommended compatibility

support, users could trivially shadow DEFINE-CONDITION and provide the

support themselves, expanding into the native DEFINE-CONDITION in the

proper syntax.

In any case, the total number of uses of DEFINE-CONDITION at this

point is probably quite small. Searching for them and repairing

each by hand is probably not an expensive operation.

Cost of Non-Adoption:

Conditions will seem harder to manipulate than other user-defined types.

People will wonder if CLOS is really something we're committed to.


A more regular, more learnable language.




Gregor, Pierson, Moon, and Pitman support this proposal.

People seem to disagree about the status that CLOS might occupy

in the upcoming standard. In spite of a vote of support, they seem

to think it might be optional in some way. Passing this proposal

establishes a clear precedent for the full integration of CLOS into

the emerging language.

The sense of the cleanup committee was that it was acceptable for

a vendor to identify a CLOS-free subset of Common Lisp, but that since

the position of X3J13 seems to be that no resources should be devoted

to work on subsets, it was inappropriate for us to work out the details

of that subset ourselves. Since nothing about this proposal would

impede such a subset, we took that to be adequate basis for presenting

this single proposal.

Moon thinks we might want to add condition types for the errors

CLOS might signal. Richard Mlynarik thinks we should add a generic

function, REPORT-CONDITION, which is used for reporting conditions.

Both of these issues should probably be pursued under separate cover.


"One comment is that you should explicitly mention bootstrapping

concerns under cost to implementors. If you just leave it out,

someone may think it is a difficult problem. "

"This isn't any sort of clarification. The actual clarification required

-- which has been requested several times, and not just by myself -- is

what the *METACLASS* of condition types is.

Condition types may be "CLOS classes" without being STANDARD-CLASSes

Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.

Just what are "normal CLOS slots"? As I see it, the "normalcy" or

otherwise of slots is determined by the metaclass.

My opinion for some time has been that condition types should not be

STANDARD-CLASSes but instead something like READ-ONLY-CLASS.

Conceptually, It Is An Error to modify the slots of condition objects,

which are supposed to be immutable descriptions of part of the state of

a computation. Implementationally,

(setf (slot-value <condition-object> <slot-name>) <new-value>) should

signal an error.

(I also think that conditions in particular have a strong need for

something like :REQUIRED-INIT-KEYWORDS, but that's another story.)

Even if you decide to make condition classes' metaclass STANDARD-CLASS,

the point is that you need to state this, so that users may define

condition classes and mixins using DEFCLASS."

"I do not agree that it is a -necessary- thing to specify the Meta-Class

of conditions because all intended uses of conditions can be done

without this information.

I agree that it is a -possibly useful- thing to do, but there is a down

side to it -- it would unnecessarily tie the hands of people who want

implementation flexibility for one reason or another."

"... If we don't specify the metaclass, then users

won't know what other classes they can mix in when defining condition

classes. It may seem weird, but I can imagine someone wanting to mix

in an arbitrary class into a condition class.

I think we should just say that the class CONDITION is an instance of

STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard

classes. Sure it might be nice to do the read only class thing but I

don't think this is a good time to design a special purpose metaclass

for this. "

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.