[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Common Lisp Types
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: Common Lisp Types
- From: Masinter.pa@Xerox.COM
- Date: 2 Feb 87 15:58 PST
- In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 31 Jan 87 09:23 PST
Strategy: We're better off leaving out classes where we have some doubts
than putting them in. New classes can be added easily later, but its
hard to get rid of things later.
Most of the classes ommitted don't belong, but for different reasons
than given:
-- types where the "type" of an object can change without going through
the change-class protocol, e.g., satisfies. Keyword is here because it
is not an error to change a keyword's home package.
-- union types (or ...) are ommitted for now because there is no natural
ordering for two different union types. Included in this is the
predefined union type COMMON.
-- range types. These include integer, floating ranges like (integer 3
12). These are omitted for the same reason that union types are omitted.
They include the predefined range types bit and fixnum. Also ommitted is
the type standard-char, which is a fairly arbitrary subset of
characters.
-- negation types. For similar reasons, types which are merely defined
as the negation of others are omitted. These include types of the form
(not x), atom, which is (not cons), and bignum, which is (and integer
(not fixnum))
We can include those implementation-dependent subclasses which have
portable language semantics: string-char, short-float, long-float,
double-float, single-float. [This is a different position than that in
the current paper.]
I much prefer having the CLOS description for function, stream (and
pathname?) be done 'right' but conditional on a corresponding cleanup of
CL than having a standard class which no implementation is required to
use or generate.
The issue is, what do you get when you say (class-of '(lambda --)). If
you insert function in the class hierarchy with RPG's definition, you
get LIST. However, this seems to violate what I think of as an
invariant, namely
for all objects x, for all classes y, (subtypep (class-of x) y) ==
(typep x y)
"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 functions."
In RPG's proposal, without a corresponding change to CL, you could get
back from
(function (lambda ...)) a list (lambda ...) for which class-of would
return the class LIST, which is not a sub-class of function.