Comment 8 for bug 1332983

If you just take ANSI CL, then it clearly seems to require that (find-class ’t) is implemented as an instance of a metaclass other than either of the three standard-class, structure-class, or built-in-class, due to the requirement that defclass cannot define any subclass of built-in-class, and due to the statement that (find-class ’t) is a system class, so neither a standard-class nor a structure-class.

CLtL2 didn’t have a notion of a system class, but there it was completely unspecified what the metaclass for (find-class ’t) was. METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED can be read as addressing the resulting inconsistency wrt (find-class ’t), among other issues.

So according to this reading, AMOP is incorrect to specify that T is a built-in-class.

However, I believe the actual specification bug is the requirement that defclass cannot specify subclasses of built-in-class. It should have specified T as an exception to that requirement, or should have stated that it’s only restricting the direct subclass relationship here. Alas, ANSI CL can’t be changed anymore.

It is also weird that ANSI CL seems to clearly imply that there is at least a fourth metaclass besides standard-class, structure-class, and built-in-class, without explicitly spelling it out.

(Along the way, I found another inconsistency in ANSI CL: The last sentence in 4.3.7 states the following: "A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the classes in the table, except for the class named t.” - referring to table 4.8. However, that table contains standard-object, which is inconsistent with the fact that any standard-class directly or indirectly inherits from standard-object. The corresponding table in CLtL2 didn’t include standard-object. Sigh…)

Pascal

On 31 Aug 2014, at 00:59, Alastair Bridgewater <email address hidden> wrote:

> Okay, good call on the specification of VALIDATE-SUPERCLASS. It is
> specifically callable by user code, and it is specifically called before
> storing the direct superclasses in a new metaclass, but it is defined in
> terms of superclass, not direct superclass. AMOP Initialization of
> Class Metaobjects specifies that VALIDATE-SUPERCLASS is called only for
> direct superclasses, but nothing prevents a custom metaclass from
> defining a BEFORE or AROUND method that does additional validation for
> whatever reason, and likewise nothing prevents any other code from
> performing such validation.
>
> The issue that we seem to be trying to dodge around, however, is if AMOP
> is incorrect to specify that Class T is a BUILT-IN-CLASS, or if CLHS is
> incorrect to specify that DEFCLASS is not allowed to create ANY subclass
> of a BUILT-IN-CLASS (rather than merely not being allowed to create
> DIRECT subclasses of a BUILT-IN-CLASS). My contention here, resting
> strongly on the issue writup for METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED
> is that the system is expected to be implementable (though not
> necessarily implemented) with just the three specified metaclasses, and
> thus Class T should be able to be one of the three specified
> metaclasses, and that the only one which makes any kind of sense is
> BUILT-IN-CLASS.
>
> Actual implementation options for the DEFCLASS restriction can come
> after we have an agreement as to the correct semantics.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1332983
>
> Title:
> validate-superclass on (find-class 't) yields NIL instead of T
>
> Status in Steel Bank Common Lisp:
> New
>
> Bug description:
> I found a minor bug that got introduced between 1.1.18 and 1.2.0.
>
> Before:
>
> * (sb-mop:validate-superclass (find-class 'stream) (find-class 't))
>
> T
>
> After:
>
> * (sb-mop:validate-superclass (find-class 'stream) (find-class 't))
>
> NIL
>
>
> The fact that I’m using (find-class ‘stream) as an example is not relevant: If the superclass is (find-class ’t), validate-superclass should always return t.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/sbcl/+bug/1332983/+subscriptions

--
Pascal Costanza