[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Common Lisp Types
- To: RPG@SAIL.STANFORD.EDU
- Subject: Re: Common Lisp Types
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 2 Feb 87 18:43 PST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 31 Jan 87 09:23 PST
- Sender: Bobrow.pa@Xerox.COM
In particular, the current Design Rationale chapter says there
are no classes for these things:
`` - Types too specific to be useful to put methods on:
bit, keyword, standard-char, string-char
I think that we must consider the rationales I gave in my message of 22
Jan 87 15:10 PST. For this case the problem is:
"c) The class of any instance should be quickly determinable. Thus
standard-char might be a case which is outlawed since it is a char that
is member of a set. Probably bit (represented by an integer that is
either 1 or 0) also falls in this category."
- Specification of the type is too vague: common, function, stream
Here the problem is whether the user is in for a surprise.
For functions, I propose that the Class Function include as
instances those objects in the Lisp that are in the range of the
function Function. For many implementations this will coincide with
Compiled-Function, which would be a subclass of Function. This
means that CLOS adopts the attitude that symbols and lists that
happen to represent functions are the second-class version of
"a) all instances of the class (or any subclass) can be identified as
being of that type. FUNCTION has a problem in that respect wrt lists. "
Perhaps we want to have methods on compiled-function.
With these two exceptions I agree with the points expressed by Dick in:
I propose that every
implementation be required to provide the classes explicitly
excluded in the design rationale except for negation classes (atom)
and Common, though there may be no instances of them, and I presume
we can arrange for the metaclass to state that fact. Furthermore, I
propose that the structure of the lattice in the vicinity of
implementation-dependent types be variable, reflecting the
implementation hierarchy. For example, if an implementation has
single-floats only, the classes would be:
(defclass short-float (single-float)) (defclass long-float
(single-float)) (defclass double-float (single-float)) (defclass
and only single-float would have instances. The other
permissible float configurations have different topology.
I propose that the class named NIL be at the bottom of the
lattice and that it also has no instances.