References: SLOT-VALUE (CLOS chapter 2)
Related issues: Issue CLOS-CONDITIONS
Category: CLARIFICATION, CHANGE
Edit history: V1, 09 May 90, Sandra Loosemore
V2, 13 May 90, Sandra Loosemore (update discussion)
V3, 29 May 90, Sandra Loosemore (clean up)
V4, 1 Jun 90, Gabriel (only proposal SPECIFY)
V5, 06 Jun 90, Sandra Loosemore (three proposals)
V6, 11 Mar 91, Sandra Loosemore (one proposal)
V7, 26 Mar 91, Sandra Loosemore (amendment from meeting)
Status: V7 (proposal LESS-MINIMAL) accepted by X3J13, Mar 1991
The description of the function SLOT-VALUE in CLOS chapter 2
requires it to be implemented using SLOT-VALUE-USING-CLASS, which
is not defined in the standard. Because of this omission, it is
not clear on what metaclasses SLOT-VALUE is defined.
There are similar problems with the description of SLOT-UNBOUND
(references SLOT-VALUE-USING-CLASS), SLOT-MAKUNBOUND (references
SLOT-MAKUNBOUND-USING-CLASS), SLOT-BOUNDP (references
SLOT-BOUNDP-USING-CLASS) and SLOT-EXISTS-P (references
SLOT-EXISTS-P-USING-CLASS, which is not even in the current MOP
It is stated in CLOS chapter 2 (in the section "Integrating Types
and Classes") that calling SLOT-VALUE on an instance of a built-in
class signals an error, but nothing is said here about the other
(1) Remove references to SLOT-VALUE-USING-CLASS,
SLOT-MAKUNBOUND-USING-CLASS, SLOT-BOUNDP-USING-CLASS, and
SLOT-EXISTS-P-USING-CLASS from the language specification. Add
implementation notes to the description of SLOT-VALUE, SLOT-UNBOUND,
SLOT-MAKUNBOUND, SLOT-BOUNDP, and SLOT-EXISTS-P which reference
the corresponding functions in the metaobject protocol document.
(2) Clarify that the function SLOT-EXISTS-P may be called with any
object as its first argument, returning true if the object has a
slot of the given name and false otherwise.
(3) Clarify that the standard defines the behavior of SLOT-VALUE, SETF of
SLOT-VALUE, SLOT-BOUNDP, and SLOT-MAKUNBOUND according to
the metaclass of their first argument, as follows:
STANDARD-CLASS -- all four functions work as already specified.
BUILT-IN-CLASS -- all four functions signal an error.
(4) Specify that the consequences are unspecified if any of the functions
SLOT-VALUE, SETF of SLOT-VALUE, SLOT-BOUNDP, or SLOT-MAKUNBOUND are
called on objects of any metaclass other than STANDARD-CLASS or
BUILT-IN-CLASS. An error might be signaled in this situation. Note
in particular that the behavior of these functions on condition
objects and objects of metaclass STRUCTURE-CLASS is unspecified.
Rationale for proposal LESS-MINIMAL:
Point by point:
(1) This gets rid of dangling pointers into hyperspace.
(2) This corresponds to the current MOP draft. It is also just what
88-002R would say if the remark mentioning SLOT-EXISTS-P-USING-CLASS
(3) This is clearly the "right" behavior.
(4) This constrains SLOT-VALUE and friends from causing "crash and burn"
errors, but doesn't overconstrain implementors.
I don't know.
Cost to Implementors:
Probably small for any of the proposals.
Cost to Users:
Cost of non-adoption:
Part of the language specification will be left vague and
The language specification is made more concise.
Making this point clear would be an improvement over leaving
This writeup has undergone a lot of revision because both the MOP
document and people's perceptions of it have also been undergoing change.
It has been difficult to find a balance between not permitting "crash
and burn" errors and giving implementations freedom to support
additional behaviors via the MOP.
The MOP draft says very little about STRUCTURE-CLASS. What it used to
say about STRUCTURE-CLASS was removed in response to concern that it
would make it more difficult to build delivery systems (a concern which
I don't share by the way). But, one thing the current draft does say is
that SLOT-EXISTS-P won't ever signal an error.
I guess my suggestion for X3J13 would be to be compatible with the MOP
draft on SLOT-EXISTS-P and "allow implementations to extend" what
happens when the slot-xxx functions are called on structure and built-in
It's assumed that, for item (1), the editor will make the implementation
notes say something that agrees with the current MOP document.