Random metaclasses for CL types

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

    Date: Sat, 13 May 89 18:10:29 PDT
    From: 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.

I completely disagree.  I do not want to define this in terms of a possibly
incomplete list of things you can do with these objects.  I want to define it
so that a program that assumes that all specified types are of metaclass
BUILT-IN-CLASS is a conforming program and will work in all implementations
regardless of what the actual metaclass is.  Can we come up with a wording
that clearly and unambiguously expresses that idea?

    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.

Since FUNCALLABLE-STANDARD-CLASS is purely chapter 3, I don't want to
digress into discussing it now.
    ....
    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.

FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is
worse.  I'm not sure that name needs to be defined in chapter 3, though;
I think it might suffice to say that the implementation provides 
GENERIC-FUNCTION with an appropriate metaclass without naming that
metaclass, particularly since chapter 3 no longer specifies the action
of the SLOT-VALUE function on any metaobject.  FUNCALLABLE-STANDARD-CLASS
may just be an artifact of the implementation used in PCL.

Now you know how this Dave feels about it.

    ....
    Why would anyone ever think 
    that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non-
    generic) functions?   Does anyone ever jump to the conclusion that Common 
    Lisp data types are elements of STANDARD-OBJECT just because of the name?

Yes.  The name STANDARD-OBJECT is definitely a problem for that reason.
It's a bit late in the day to change it, though, and I don't recall ever
hearing a suggested name I liked better, even though this has been
discussed on several occasions in the past.