atom type question

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Tue, 12 May 1987  10:05 EDT
    From: Ram@C.CS.CMU.EDU
	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.