CONDITION-SLOTSCL draft specification from last fall refer to slots of specified conditions. However these slots were not put into the specification in a consistent way.
CLOS-CONDITIONS:INTEGRATE, which was adopted by X3J13, changed condition slots to be the same as CLOS slots, but did not say that the specified conditions have any specified slots. However, some people have taken it to mean that the condition classes defined by the standard all contain slots whose names are external symbols in the CL package which are STRING= to the specified initargs for creating conditions. The ANSI CL draft specification was edited in some places as if this were true.
Revision 18 of the conditions document, which was adopted by X3J13, refers to initialization arguments and accessors, but carefully avoids naming the slots themselves. The philosophy of that document was that slots are only defined for programmer defined conditions, and that the only sanctioned interface for the standard condition classes is through the use of the defined accessor functions.
A related, more general issue that PACKAGE-CLUTTER:REDUCE failed to address is whether there are naming restrictions on implementation-dependent slots of specified classes.
This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.
DEFINE-CONDITION form.
2. Table 5-1 in the ANSI CL draft specification should not contain slot names, because they will not necessarily be accessible via WITH-SLOTS in the way people might infer. Instead, the table should mention initargs and accessors. For example, :FORMAT-STRING and SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.
3. Define that it is unspecified whether slots are involved in the operation of specified functions on instances of specified classes, except when slots are explicitly specified by the standard.
4. Define that if in a particular implementation a specified class has slots that are not specified by the standard, the names of these slots must not be external symbols of packages defined in the standard nor otherwise accessible in the USER package.
Specifying slots for the condition classes would require putting the slot names into the COMMON-LISP package, adding many symbols.
Part 4 of the proposal repairs an omission in PACKAGE-CLUTTER:REDUCE. It is necessary if users are to be able to define a subclass of a condition class (which is necessary whenever users define their own conditions) and give slots to their class without potentially interfering with implementation-defined slots.
SLOT-VALUE or WITH-SLOTS to access information in conditions.COMMON-LISP package and considerable extra work on the ANSI CL specification to document all the slots. Porting problems for any code that defines its own condition types because of slot name collisions.SLOT-VALUE might be faster than calling an accessor in some implementations (although in most implementations it is slower, when not called from a method), but access to a slot of a condition never occurs in important inner loops.