Comment 2 for bug 1332983

I haven't found a flaw in your reasoning, but I have some possibly tighter
reasoning for you:

* Class T is a superclass of every class except itself (CLHS 4.3.1,
"Introduction to Classes")

* It is forbidden for DEFCLASS to create subclasses of a BUILT-IN-CLASS
(CLHS, "System Class BUILT-IN-CLASS"; CLHS 4.3.7, "Integrating Types and
Classes", possibly further repeats).

* DEFCLASS would therefore be useless if T were a BUILT-IN-CLASS.

I see two ways forward. One is to ignore the restriction on AMOP table
5.1. The other is to declare that the restriction on subclassing
BUILT-IN-CLASS with DEFCLASS is only for DIRECT subclasses, not subclasses
generally. DEFCLASS (CLHS, "Macro DEFCLASS") says that it defaults to
creating subclasses of STANDARD-OBJECT, which is a direct subclass of T,
but the new class defined is a merely indirect subclass of T and thus would
be legal by this interpretation.

On Thu, Aug 28, 2014 at 9:14 AM, Christophe Rhodes <
<email address hidden>> wrote:

> So, consider the following points:
>
> * T must name a built-in-class (AMOP, "Inheritance Structure of
> Metaobject Classes")
>
> * `(validate-superclass <any class> (find-class t))' must return t
> (AMOP, Dictionary entry for validate-superclass)
>
> * validate-superclass determines whether a class can be a direct
> superclass
>
> * trying to subclass a class of metaclass built-in-class signals an
> error (CLHS, "System Class BUILT-IN-CLASS")
>
> as far as I can tell, these four points are an inconsistency. Of
> course, it doesn't explicitly say that returning t from
> validate-superclass means that attempting to define the subclass is an
> error, but it's clearly the intent and I don't really want to
> language-lawyer to that extent. Also, where there's conflict we attempt
> to preserve the ANSI spec over AMOP. So, that means that either
> (validate-superclass <class> (find-class t)) should be allowed to return
> false, or else t should be allowed not to be a built-in-class.
>
> I would tend towards making T a SYSTEM-CLASS (a superclass of
> BUILT-IN-CLASS) but maybe someone else has an opinion? Or can point out
> a flaw in my reasoning?
>
> Christophe
>
> --
> You received this bug notification because you are subscribed to SBCL.
> 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
>