Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Feb 89 15:31:03 CST
From: David N Gray <Gray@DSG.csc.ti.com>
Page 1-15 of 88-002R says that
"Each class that corresponds to a predefined Common Lisp type
specifier can be implemented in one of three ways ... a standard
class ..., a structure class ..., or a built-in class ..."
Shouldn't this also permit the possibility of other
implementation-specific metaclasses? For example, in our current
implementation the class PATHNAME is an instance of metaclass
FLAVOR-CLASS.
There is a compatibility question that needs to be answered. Right now,
pathname is not supposed to be a class, so the question is mute, but when it
will be, its metaclass has to be compatible with standard-class, so a portable
program can inherit from it, and specialize some methods on it, as if it were a
standard-class instance.
Page 1-27 says that the default argument precedence order is left to
right, but I wonder if in the case of (SETF ...) functions it wouldn't
make more sense for the default order to put the new-value argument last
instead of first? This wouldn't normally change the semantics, but it
could affect efficiency.
Maybe it does affect efficiency in some implementations, but I don't think it
has to. I think that the user would be confused if we establish different
default rules for setf generic functions. I except user changing the default
procedence order if they know that the value is not significant for
discrimination.
I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
generic functions with a primary method on class STANDARD-OBJECT which
just invokes a SLOT-...-USING-CLASS generic function. Do these really
need to be generic at both levels? According to the specification,
SLOT-BOUNDP, for example, should be implemented as
Note that the latter parallels the way that SLOT-VALUE is specified.
I think we said that was a bug. They all should be functions like slot-value.