[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 <jonl@lucid.com>
- Date: Thu, 11 May 89 06:28:56 PDT
- Cc: chapman%aitg.dec@decwrl.dec.com, common-lisp-object-system@sail.stanford.edu
- In-reply-to: David A. Moon's message of Wed, 10 May 89 13:31 EDT <19890510173122.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
re: . . . or any other implementation-defined
class that is no more restrictive than a {\bit built-in class\/}.
I liked your first version better -- I don't remember 88-002R having
a well-ordered scale for "restrictiveness" of metaclasses, so this
phrase (for me) causes much more confusion than it clears up. But
it's not a big point.
On a related theme -- I was wondering if everyone agrees that the
following is also permitted by "Integrating Types And Classes" section.
An implementation may have a subset of some built-in class being
implemented by a different meta-class than the rest of the set. For
example, in most implementations we probably have:
(class-name (class-of (find-class 'integer))) --> BUILT-IN-CLASS
But some implementation might also have a FIXNUM class such that:
(class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS
where FAST-ARITH-CLASS is not a subclass of BUILT-IN-CLASS. Of course,
the FIXNUM class is a still a subclass of INTEGER.
[don't take this example too seriously -- I'm more concerned about
subclasses of the FUNCTION class.]
Assuming that this is legit, then I guess the point you are trying to
clear up is whether or not it is valid for the subset to be the
whole set -- i.e., some CL type is wholly implemented by a moderately
random metaclass.
-- JonL --