CLOS-CONDITIONSDEFSTRUCT 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.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
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR)
((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
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 (DEFMETHOD PRINT-OBJECT ((X c) STREAM) (IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
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*.
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
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR)) would be rewritten (DEFINE-CONDITION FOOBAR (FOO BAR) ((X :INITARG :X :READER FUBAR-X) (Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ()) (DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM) (IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (FORMAT STREAM "Oops! Something went wrong."))) (ERROR 'OOPS) >>Error: Oops! Something went wrong.
CLOS probably already do this, or something very similar.CLOS, this is very straightforward.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.
People will wonder if CLOS is really something we're committed to.
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. "
----- End Forwarded Messages -----