Re: Random metaclasses for CL types

[David N Gray <Gray@DSG.csc.ti.com>]

> Except for Chap 3, it hasn't even spoken about what relationship,
> *** if any **, there is between the metaclass of FUNCTION and that of 
> STANDARD-GENERIC-FUNCTION.  Have we finally agreed even if FUNCTION 
> is implemented as BUILT-IN-CLASS, this places no particluar constraint 
> on what the class of STANDARD-GENERIC-FUNCTION is?  including whether or 
> not it is BUILT-IN-CLASS or STANDARD-CLASS?

I would say:
  (TYPEP (FIND-CLASS 'FUNCTION) 'BUILT-IN-CLASS) => <implementation-dependent>
  (TYPEP (FIND-CLASS 'STANDARD-GENERIC-FUNCTION) 'BUILT-IN-CLASS) => NIL  
  (TYPEP (FIND-CLASS 'STANDARD-GENERIC-FUNCTION) 'STANDARD-CLASS) => T

because if STANDARD-GENERIC-FUNCTION were a BUILT-IN-CLASS, then users
would not be able to define subclasses of it and those subclasses
couldn't define slots.

> What I was trying to illustrate with the bifurcated tree:
> 
>                       function 
>                        /     \
>                      /         \
>                    /             \
>                  /                 \
>           generic-function    standard-function
>                  \                 /
>                    \             /
>                      \         /
>                        \     /
>               standard-generic-function
> 
> 
> is that we could have somewhat random metaclasses for GENERIC-FUNCTION 
> and STANDARD-FUNCTION; hence, even though STANDARD-GENERIC-FUNCTION is
> a subclass of both, it could have a totally different metaclass.  The 
> constraints needed for metaclass "compatibility" don't seem to be
> encompassed by subclass relationships.

OK; the real issue is that if users are to be permitted to define
subclasses of GENERIC-FUNCTION or STANDARD-FUNCTION, then they just need
to know what to use for the :METACLASS option for their class in order
for the inheritance to be permitted.

> In fact, GENERIC-FUNCTION seems almost worthless.  What might show
> a truer picture is a GENERIC mixin, which when combined with
> STANDARD-FUNCTION yields STANDARD-GENERIC-FUNCTION.  But I must confess
> that the GENERIC mixin probably wouldn't be of use anywhere else.

I don't see the difference.  Isn't GENERIC-FUNCTION already understood
to be a class that is not directly instantiated?