[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
atom type question
- To: Ram@C.CS.CMU.EDU
- Subject: atom type question
- From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
- Date: Tue, 12 May 87 20:50 EDT
- Cc: common-lisp@SAIL.STANFORD.EDU
- In-reply-to: <RAM.12301785477.BABYL@>
Date: Tue, 12 May 1987 10:05 EDT
Date: Tuesday, 12 May 1987 06:00-EDT
From: Christopher Fry <cfry at OZ.AI.MIT.EDU>
Is ATOM supposed to be true of non-COMMON data types as well?
I think the language in the manual pretty clearly indicates that the
answer is yes, although there currently isn't much discussion of
extensions to the type system. CONS is a subtype of COMMON and ATOM =
(NOT CONS), therefore anything not COMMON must be an ATOM.
In can't see any reason for wanting thing to be otherwise. If you
want to add some new object that acts like a cons but isn't, then you
can make it a subtype of cons.
I agree with this, except I don't believe in the type
COMMON. You can get the same result by omitting references
to COMMON: If it's not a subtype of CONS, by ATOM = (NOT CONS),
it must be an ATOM.
Although CLTL says that
"implementations may not unilaterally add subtypes to COMMON", I think
that there is no way for a correct program to tell that you have added
a subtype except in the cases where CLTL says that some types form an
exhaustive partition of another type.
Not even then, because you may be partitioning an one of those
types further, or extending one to contain additional elements.
COMMON is a joke. Without any clear statement of just what
COMMONP is supposed to buy you, it's impossible to come up
with any clear view of what it should mean. What happens
if Common Lisp '89 comes out, and defines 6 new types? Without
any advance knowledge of how this extension would be handled,
you can't write you code defensively using COMMON.
Instead, in situations where you try to handle all of the
types in CL, I believe you should just use ETYPECASE naming the
types you actually DO handle. Extended types will either fit
in with types you implemented (say a new subtype of CONS will
fit in with your LIST clause), or they won't.