Random metaclasses for CL types

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

re: [The "holy" types of 88-002R, pages 1-16 and 1-17] I want to define it 
    so that a  program that assumes that all specified types are of metaclass 
    BUILT-IN-CLASS is a conforming program and will work in all implementations
    regardless of what the actual metaclass is.  Can we come up with a wording
    that clearly and unambiguously expresses that idea?

Well, foo, this loosely worded specification implies that the metaclasses
of the "holy" types are in fact subclasses of BUILT-IN-CLASS.  And that's
precisely what I thought you were trying to avoid prescribing.

The example discussed in previous mail --  STANDARD-FUNCTION-CLASS (?) --
wasn't shown as a subclass of BUILT-IN-CLASS precisely because Chap 3
requires it to be a direct sublcass of STANDARD-CLASS instead.  I wouldn't
be against changing this and simply saying, quite up-front, that all
implementation-specific metaclasses covering the "holy" types must
be subclasses of BUILT-IN-CLASS (i.e. those which are not of metaclass
STANDARD-CLASS or STRUCTURE-CLASS).

Perhaps we could investigate the possibilities of having a broad enough 
definition for BUILT-IN-CLASS so that your flavor-implemented types could 
be covered?  I don't see much in 88-002R that overly constrains built-in
classes.


re: FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is
    worse.  I'm not sure that name needs to be defined in chapter 3, though;
    I think it might suffice to say that the implementation provides 
    GENERIC-FUNCTION with an appropriate metaclass without naming that
    metaclass, particularly since chapter 3 no longer specifies the action
    of the SLOT-VALUE function on any metaobject.  FUNCALLABLE-STANDARD-CLASS
    may just be an artifact of the implementation used in PCL.

The point of STANDARD-FUNCTION-CLASS is *not* that it is the metaclass of
GENERIC-FUNCTION, but rather of an orthogonal set of functions that have 
"standard" structure.   PCL uses it to make "constructors", which are 
functions but not generic-functions.  You're right that this is probably a
PCL-inspired artifact; but it's not completely senseless.  It's justifiable
in Chap 3 only to the extent that someone else might want to do something
like PCL's constructors.  I'll leave it to Gregor to defend them.  But if
you think it's unlikely that Chap 3 will have a serious impact, then
perhaps it isn't worth discussing yet.


Since no one objected to the subclass links in my earlier mail , I take it 
that the following subclass graph is obvious [regardless of the metaclass 
links]?

                      FUNCTION
                     /   |    \
                    /    |     \
                   /     |      \
                  /      |       \
                 /       |        \
                /        |         \
               /         |          \
   GENERIC-FUNCTION  {OtherFuns}  {STANDARD-FUNCTION}
              \                      /     |    \
               \                    /      |     \
                \                  /       |      \
                 \                /        |       \
                  \              /         |        \
                   \            /          |         \
                    \          /           |          \
             STANDARD-GENERIC-FUNCTION  {Hunoz?}  {PCL-Constructors}



-- JonL --