The T and NIL issues

[Symbolics Technical Staff]

I'm sorry this message has been so long delayed; my time has been
completely occupied with other projects recently.

We have had some internal discussions about the T and NIL issues.  If we
were designing a completely new language, we would certainly rethink these,
as well as the many other warts (or beauty marks) in Lisp.  (We might not
necessarily change them, but we would certainly rethink them.)  However,
the advantages to be gained by changing T and NIL now are quite small
compared to the costs of conversion.  The only resolution to these issues
that Symbolics can accept is to retain the status quo.

To summarize the status quo:  NIL is a symbol, the empty list, and the
distinguished "false" value.  SYMBOLP, ATOM, and LISTP are true of it;
CONSP is not.  CAR, CDR, and EVAL of NIL are NIL.  NIL may not be used
as a function nor as a variable.  NIL has a property list.  T is a symbol
and the default "true" value used by predicates that are not semi-predicates
(i.e. that don't return "meaningful" values when they are true.)  EVAL of
T is T.  T may not be used as a variable.  T is a keyword recognized by
certain functions, such as FORMAT.

The behavior of LISTP is a change to the status quo which we agreed to long
ago, and would have implemented long ago if we weren't waiting for Common
Lisp before making any incompatible changes.  The status quo is that NIL
has a property list, however this point is probably open to negotiation if
anyone feels strongly that the property-list functions should error when
given NIL.

The use of T as a syntactic keyword in CASEQ and SELECTQ should not be
carried over into their Common Lisp replacement, CASE.  It is based on a
misunderstanding of the convention about T in COND and certainly adds
nothing to the understandability of the language.

T and NIL are just like the hundreds of other reserved words in Lisp,
dozens of which are reserved as variables, most of the rest as functions.
Any particular program that wants to use these names for ordinary symbols
rather than the special reserved ones can easily do so through the use of
packages.  There should be a package option in the portable package system
by which the reserved NIL can be made to print as "()" rather than
"GLOBAL:NIL" when desired.