Random metaclasses for CL types

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

re: . . .  what one-line change to make to the draft ANSI Common Lisp
    spec where it says what a conforming program can assume about the
    behavior of objects of the built-in types.

I fear it won't be one-line change.  Would you be happy if we could all
agree to a two-dozen line change?

If so, then I think I could go for Gabriel's plan to flush BUILT-IN-CLASS
as a required class, providing that we add an implementation-revealing
defconstant -- say, BUILT-IN-CLASSES  -- which is just a list of all the 
classes supporting "built in" types.  The "holy" types of pages 1-16 and 
1-17 would be required to have representatives  on this list, and an 
implementation would be free to add as many others as necessary to 
provide reasonable support so that CLASS-OF is a total function.

As I've previously argued, the only utility of BUILT-IN-CLASS is taxonomic;
and this capability can just as easily and naturally be provided by a list 
of all such classes.  [By the bye, "holy" because they are set apart for a 
transcendent purpose.]  A list is better than a predicate BUILT-IN-CLASS-P
since one might never know to look for the very implementation-specific
classes.


Secondly, I still tend to think that the notion of "restriction" isn't
clear enough.  One man thinks it means no use of SLOT-VALUE; another
sees it as no MAKE-INSTANCE; yet a third is concerned that it might 
even mean "can't appear in the cdr of a list".  By letting all the
"holy" types have metaclasses of unspecified nature (but of course
every metaclass itself is a very standard object), implementations
are free to let "built-in" classes respond to any protocol whatsoever. 
However, the standard will not specify any CLOS operations on the "holy"
types, so that portable code can depend only on existence of such
classes (for use as specializer names).

Thus I would also agree with Gabriel that we could get along nicely 
without specifying any restrictions on built-in classes.  I'm not
happy with the idea of end-users defining subclasses of INTEGER and
VECTOR, but . . . well, this really is an implementational matter;
after all, I probably wouldn't have thought of wanting to have my
own subclasses of PATHNAME either.


-- JonL --