Random metaclasses for CL types

[Patrick Dussud <dussud@lucid.com>]

   Date: Fri, 19 May 89 07:23:58 PDT
   From: Jon L White <jonl>

   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.

I disagree. 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. 

   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).
I would be against it. 

   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.

I would be against having Flavor's metaclass be a subclass of BUILT-IN-CLASS.
Flavors are much closer to STANDARD-CLASS than they are from BUILT-IN-CLASS. 

   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}


As far as the standard is concrned, we are interested only in:


                      function 
                         |
                  generic function
                         |
              standard-generic-function

and that's OK with me.