T and NIL

[Guy.Steele at CMU-10A]

As nearly as I can tell, the arguments about changing NIL to () may be
divided into these categories (I realize that I may have omitted some
arguments--please don't deluge me with repetitions of things I have left
out here):

Aesthetics.
   Pro: NIL is ugly, especially as the empty list.
   Con: () is ugly, especially as logical falseness.

Convenience.
   Pro: Predicates such as SYMBOLP can usefully return the argument.
   Con:	If you change it then the empty list and false don't have property
	lists.

Compatibility.
   Con: Old code may be incompatible and may not be mechanically convertible.
	There is a large investment in old code.
		[I cannot resist noting here that the usual cycle of life
		continues: the radicals of 1975 are today's conservatives.]
   Pro: A small amount of anecdotal evidence indicates that old code that
	actually does depend on the empty list or falseness being a symbol
	has a bug lurking in it.

Inertia.
   Con: LISP has always used NIL, and people are used to it.
   Pro: It isn't difficult to get used to ().  Not only NIL has tried it;
	the Spice LISP project has used () for over a year and has found
	it quite comfortable.
   Con: Nevertheless, many people remain unconvinced of this, and this
	may serve as a significant barrier to getting people to try
	Common Lisp.

Implementation.
   Pro: In non-microcoded implementations, it is difficult to make
	CAR and CDR, SYMBOLP, and symbol-manipulating functions all
	be as efficient in compiled code as they might be if NIL and ()
	were distinct objects.

Ad hominem.
   [I will not dignify these arguments by repeating them here.]

Different people weigh these categories differently in importance.
I happen to lay great weight on aesthetics (the Pro side), convenience,
and implementation, and much less on compatibility and inertia.

Someone has also pointed out that the argument from implementation would
disappear if CAR and CDR of NIL were no longer permitted.  This strikes
me as quite perceptive and reasonable.  However, I am quite certain that
hundreds of *correct* programs now depend on this, as opposed to the
programs (whose very existence is still doubtful to me) that, correctly
or otherwise, depend on () being the symbol NIL.

Therefore I remain convinced that making the empty list *not* be a symbol
is technically and aesthetically the better choice.


HOWEVER, the primary purpose of Common LISP is not to be maximally
elegant, nor to be technically perfect, nor yet to be implementable with
maximal ease, although these are laudable aims and are important
secondary goals of Common LISP.

	The primary goal of Common LISP is to be Common.

If so trivial and stupid an issue as () versus NIL will defeat efforts to
achieve this primary goal; and, which is more important, if inertia and
unfamiliarity might prevent new implementors from adopting Common LISP;
then I must yield.  I speak for myself, the Spice LISP project, and the
new DEC-sponsored VAX Common LISP project: we will all yield on this issue
and endorse the traditional role of NIL as symbol, falseness, and empty
lists, for the sake of preserving the commonality of Common LISP.

Similar remarks apply to T and #T; for the sake of commonality, #T ought
not be a part of Common LISP (but neither should Common LISP usurp it).

This issue must be settled soon; many outside people think that because
we haven't settled this apparently fundamental matter therefore Common
LISP is nowhere close to convergence.  Moreover, *any* decision is better
than trying to straddle the fence.

In any event, something has to go into the next draft of the manual,
pending what I hope will be a final resolution of this issue at the next
face-to-face meeting.  Since every major project (with the possible
exception of Vax NIL?) is now willing to go along with the use of the
symbol NIL as the false value and empty-list and with the use of the
symbol T as the standard truth value, this seems to be the only
reasonable choice.

--Guy