Random metaclasses for CL types

[Jon L White <jonl@lucid.com>]

re: . . . It means that the external protocol supported by the
    implementation dependent metaclass needs to cover the capabilities
    BUILT-IN-CLASS. This can be achieved independently of the taxinomy of
    metaclasses. I don't think we want the users to rely on the taxinomy of
    metaclasses at this point. 

On the first two  points, we are quite in agreement.  But the taxonomy 
*is* user-visible; and for any flavor-implemented "holy" type, it wouldn't 
satisfy all the BUILT-IN-CLASS capabilities unless it had a similar
hierarchy.  Unless Moon wants to be more explicit on what he wants
out of portability of BUILT-IN-CLASS, I would have to assume that it
includes taxonomy.

Now, as Gray says, flavor-implemented classes **in general** have some 
structural features that BUILT-IN-CLASS types don't have.  But this isn't 
an argument against using a particlar one to support a BUILT-IN-CLASS 
element, because a sufficiently-restrictive set of methods on that
flavor-implemented class will strip it of its apparent slots.   On the
other hand, why shouldn't some limited set of BUILT-IN-CLASS elements
respond to, say, SLOT-VALUE?  The question is, How do you view the
limitations of BUILT-IN-CLASS -- as merely a limit on what is guaranteed
to be available, or as an absolute prohibition on what shall not be
available?

If anything, the trouble we seem to be having in pinpointing the problem 
is that BUILT-IN-CLASS is a purely synthetic concept that agglomerates 
numerous totally-independent structures [e.g., how is FLOAT, say, related
to SYMBOL?].  The only thing that relates them together -- regardless of 
their inner details (e.g "standard" slots or not) is their opacity in
the class system.  I.e., you can specialize on their type, but you can't 
generally do any other structural operations such as "make an instance", 
expose a "slot", etc.


Now, in the FUNCTION domain, it's true that the standard so far has 
only spoken about:

                      function 
                         |
                  generic function
                         |
              standard-generic-function

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?

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.

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.


One last point -- as Gray mentions, there isn't an obvious meaning
for STANDARD-FUNCTION.  I've abstracted that from what Gregor calls
"funcallable instances" in PCL.  The trouble with the latter term
is that *all* functions are "funcallable instances" in some sense,
in that you can FUNCALL them.  The crucial difference is in a little
protocol puts two "slots" into an othewise vanilla funtion; this is
what makes them "standard" in my view.  

Mostly I'm raising these issues about subclasses and metaclasse of  
FUNCTION as a Chap 3 point, since it is there where substructure of 
FUNCTION can be exposed.  And I think it is a good thing to do so,
since expert Lisp users have *always* wanted to know the structure
of functions and tinker with them in some superficial but tremendously
useful way.  PCL's "fins" are a prime example of this, and I don't 
suspect that they'll be the last.



-- JonL --