Random metaclasses for CL types

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

re: . . .  The idea is that
    if a user program assumes it might be a built-in-class, an implementation
    can't screw the user over by coming with an implementation-defined class 
    that's even worse (can't appear as the cdr of a cons or something).

Maybe a positive way to say this is that such instances must be "first-class"
-- i.e, can be passed as arguments to functions, can be cons'd into list 
structure, can be specialized upon by generic functions, don't crash the
system if you try to print them, etc.   Better to know where the alligator 
*is* than where he isn't.


re: Or maybe you really meant that 
	   (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS
    but
	   (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS
    and
	   (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL
    which is specified either by 88-002R or the draft metaobject protocol,
    I forget which.  Anyway this example shows that you don't have to worry.

Why, yes, as a matter of fact, that's precisely what I was hinting at.

However I don't see any particular consequence of requiring
FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather
than of BUILT-IN-CLASS.  It's certainly possible for one subclass of
STANDARD-CLASS to paint a totally different picture of its instances 
than some other random subclass of STANDARD-CLASS does.

Also, I don't feel strongly that non-FUNCALLABLE-STANDARD-CLASS function 
classes should have a separate name from FUNCTION -- to form a partition 
as you were suggesting in:
    "... where SLOW-ARITH-CLASS and FAST-ARITH-CLASS are disjoint 
     subclasses of BUILT-IN-CLASS?"
[presumably you also meant also that the union of SLOW-ARITH-CLASS and 
FAST-ARITH-CLASS would conver the INTEGER class].  Rather,  I would like 
to see a clear picture as follows, where the dots show metaclass links, 
and the slashes show subclass links:

	      FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS
	     /        \
	    /          \
	   /            \
	  ??   STANDARD-FUNCTION-OBJECT  . . . . . . . STANDARD-FUNCTION-CLASS
		/                 \
	       /                   \
	      /                     \           GENERIC-FUNCTION
	     /                       \              /
	    /                         \            /
  {PCL's "constructors"}      STANDARD-GENERIC-FUNCTION

The advantage of using the name STANDARD-FUNCTION-CLASS rather than
FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already
established between the nomenclatures of certain other meta objects:

   STANDARD-OBJECT             --  STANDARD-CLASS
   STRUCTURE-OBJECT            --  STRUCTURE-CLASS
   {BUILT-IN-OBJECT}           --  BUILT-IN-CLASS
   {STANDARD-FUNCTION-OBJECT}  --  STANDARD-FUNCTION-CLASS

[The names in {}'s show classes that aren't specified in the standard,
but which people informally talk about using various names].  The ?? 
class under FUNCTION above would be left for implementation-specific 
functions, which don't have the regular structure about them that allows 
easy (perhaps "portable") manipulation of subcomponents.  This is what
STANDARD-FUNCTION-CLASS would represent -- regular, accessible structure
of the functions.  I'd be particularly curious as to how you two Daves 
feel about this.


-- JonL --