# editorial correction to CLOS stuff

I think this is small enough that it doesn't need to go through the
X3J13 cleanup process.  If anyone disagrees please let me know.
Kathy: I assume this text migrated into the X3J13 draft specification,
although I didn't find it in an excessively quick look through the
parts that happened to be in my office.  If no one objects, could you
update it?

Page 1-15 of 88-002R says

Each class that corresponds to a predefined Common Lisp type specifier
can be implemented in one of three ways, at the discretion of each
implementation.  It can be a {\bit standard class\/} (of the kind
defined by {\bf defclass}), a {\bit structure class\/} (defined
by {\bf defstruct}), or a {\bit built-in class\/} (implemented in
a special, non-extensible way).

This can be interpreted to mean that the metaclass of an object of a
predefined Common Lisp type can only be one of standard-class,
structure-class, or built-in-class, and no others.  I don't think
that was intended.  I don't think it was even intended that the
metaclass must be a subclass of one of those classes.  One example
where this came up is an implementation with Flavors, that implements
some predefined Common Lisp types using Flavors.  The metaclass of
a Flavors instance is certainly not any of those three.  I would