re: Random metaclasses for CL types

[David N Gray <Gray@dsg.csc.ti.com>]

> I think the real concern is that some implementations might wish to allow
> even the holy types to respond to these protocols. I think we don't want
> to prevent it.

But that is easily handled by allowing the implementation the freedom to
decide which classes are BUILT-IN-CLASSes; we don't need to change the
definition of BUILT-IN-CLASS.

> In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone
> writing a portable program couldn't devise a more portable solution to the
> problem, especially if there is alternative that is used if the
> 
>   (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)
> 
> returns T.
> 
> Are you thinking of a portable programming environment?

Suppose I were trying to write a portable inspector.  If an object is an
instance of a built-in class, then probably all I can do with it is to
invoke the implementation-supplied DESCRIBE-OBJECT method, but if it is a
STANDARD-CLASS, then I can do interesting things with its CLASS-SLOTS
list.  According to page 3-81 of document 89-003, CLASS-SLOTS simply
returns NIL for a BUILT-IN-CLASS, so how else would I know the difference
between a standard object that has no slots versus an object implemented
in some way that I can't look inside of?