[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Random metaclasses for CL types
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Random metaclasses for CL types
- From: Jon L White <firstname.lastname@example.org>
- Date: Thu, 25 May 89 09:04:42 PDT
- Cc: RPG@SAIL.Stanford.EDU, email@example.com, Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.Stanford.EDU, firstname.lastname@example.org
- In-reply-to: David A. Moon's message of Wed, 24 May 89 13:46 EDT <19890524174658.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
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
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 --