Random metaclasses for CL types

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

re: The other alternative is to flush built-in-class and let imlementations 
    decide their own metaclass hierarchy. Maybe that way we would see some
    implementors doing some innovative design.

Before doing that, we should reflect on why BUILT-IN-CLASS is in the
standard, and why 88-002R specifies that the "holy" Common Lisp types
should be of metaclass either BUILT-IN-CLASS, STRUCTURE-CLASS, or
STANDARD-CLASS.  After all, our present problem is determining how to 
say the intent that Moon wants to add to 88-002R, page 1-15, about 
"restrictions" on implementation-dependent metaclasses.

After talking it over with you (RPG), I think we have been overly
concerned  with the aphorism "The Metaclass implements the structure
of the instances".  In fact, this just isn't true of all Metaclasses;
the fact that it is a concise description of the structure of
STANDARD-CLASS has fooled us into thinking it to be more widely true.

I see BUILT-IN-CLASS as a series of "fronts" for objects that exist
in a Common Lisp implementation's extended type hiearchy.  The structure
of these "instances" __is not__ implemented by any facility whatsoever
in the Common Lisp Object System, but by all of "the ususal suspects",
such as microcode, machine-language assembly code, Lisp functions, 
compiler tricks, etc.  The sole raison d'etre of BUILT-IN-CLASS is so 
that generic functions may discriminate on these "holy" types (but 
probably not on lots of other types about which no one cares).

Viewed in this light, there is no reason at all why the flavor-implemented
types shouldn't simply be represented by a place-holder class that is either
an instance of BUILT-IN-CLASS, or some implementation-dependent subclass
thereof.

The question should arise: Why not require all "holy" types to be of
metaclass BUILT-IN-CLASS (or implementation-dependent subclass thereof)?
The answer comes from the fact that CLOS _does not_ provide for true
information/structure hiding such as, say, Common Objects has.  Thus if 
some implementation should support a "holy" type by using a STANDARD-CLASS,
this would be visible to the end user.  Furthermore, any attempt to apply 
some restrictions to such a metaclass (such as by providing overrides for 
SLOT-VALUE-ABUSING-CLASS to make it look to the user like these classes 
don't have slots) would also apply to the implementor, thereby totally 
nullifying the advantage or using a STANDARD-CLASS in the first place.

Thus, because of the openess of CLOS, STRUCTURE-CLASS and STANDARD-CLASS
must be allowed explicitly; but _any_ other implementational technique
needs only BUILT-IN-CLASS as a "front", regardless of whether it is by
microcode, by flavors classes, or by YetAnotherObjectSystem.


-- JonL --