[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Random metaclasses for CL types
- To: Jon L White <email@example.com>
- Subject: Random metaclasses for CL types
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 18 May 89 15:06 EDT
- Cc: Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, firstname.lastname@example.org
- In-reply-to: <8905140110.AA18947@bhopal>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Date: Sat, 13 May 89 18:10:29 PDT
From: Jon L White <email@example.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
(class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS
(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.