editorial correction to CLOS stuff

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

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
change that paragraph to read

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four 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}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or any other implementation-defined
  class that is no more restrictive than a {\bit built-in class\/}.

The paragraphs after it don't need to be changed.