Hi,

Sorry for chiming in so late.

One assumption that Christophe made in an earlier email is, I think, not correct: validate-superclasse doesn’t specify that it determines whether the class /superclass/ is suitable for use as a /direct/ superclass of /class/, but whether it is suitable as [just] a superclass of /class/. (So no mention of “direct” in the wording in AMOP, which implies that it applies to both direct and indirect superclasses.)

So here is a reading that, I believe, makes the specs more consistent with each other: A CLOS implementation can ensure that users cannot define direct subclasses of T in some way independent of validate-superclass, but validate-superclass can be specialized by users to define /additional/ restrictions, and those restrictions are defined in terms of the (transitive) superclass relationship, not the direct superclass relationship. So T cannot be a direct superclass of a standard-class, which could be checked say by the defclass macro expansion or by ensure-class, but it is always a valid indirect superclass, and that is what validate-superclass - correctly - yields.

This may sound like stretching things, under the assumption that the authors of ANSI CL and AMOP had all implications in their heads, which is not necessarily the case - especially since validate-superclass is only called on direct superclasses. However, it is the case that the specification for validate-superclass does make use of the terms “direct superclass” and (just) “superclass” in different places, so this is an indication that this distinction was made on purpose. Also note that the specification for validate-superclass explicitly states that it can also be called by user code, so maybe the idea was that from a user code perspective, covering both direct and indirect classes was considered more valuable.

Does this make sense?

Pascal

On 30 Aug 2014, at 06:22, Alastair Bridgewater <email address hidden> wrote:

> Okay, I concur with your interpretation of AMOP ``Initialization of
> Class Metaobjects'' in Chapter 6 (as opposed to the misleadingly
> identically named section in Chapter 5), and agree that transitive
> handling of the full CPL makes sense.
> 
> But here's the next wrinkle that I see: This section is about the use of
> MAKE-INSTANCE to construct a class metaobject, not about the use of
> DEFCLASS.  AMOP 5.4.2 says that DEFCLASS does some transformation of
> slot descriptions and whatnot and then punts to ENSURE-CLASS.  ENSURE-
> CLASS calls ENSURE-CLASS-USING-CLASS calls MAKE-INSTANCE on the
> metaclass, leaving no further reasonable hook, but denying direct
> inheritance from T in DEFCLASS itself looks like it would be conforming
> to both CLHS (under the "the inheritance prohibition is against DIRECT
> subclasses" interpretation) and AMOP, including the requirement for
> class T and still leave the door open for your completely new object
> protocol bit.
> 
> -- 
> 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