Re: T and NIL

[HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)]

If you are calling for a vote, here are mine.

On truth:  1, 2A, 2, 3.  As long as you are going to say that everything
non-NIL (non-()?) is true, it seems completely pointless to add a new
data-type to represent truth.

On emptiness:  1, 2, 3.

I feel very strongly about the undesirability of allowing differences
among implementations.  I feel less strongly about the undesirability
of changing T and NIL to #T and ().

Mostly, I simply don't understand the reason for changing NIL and T.  I
thought the goal of CL was to make changes only when there is some
reason for them.  The only reason I can figure out is that people find
it inelegant that T and NIL look like symbols but don't quite work like
normal symbols.  However it seems at least as inelegant to add a new data
type for each of them.  Particularly when the most likely proposals
leave NIL and T so they can't be rebound, thus not really solving the
problem of having NIL and T be odd.

By the way, I have another issue that is going to sound trivial at
first, but which may not end up to be:  Does anyone care about whether
Lisp code can be discussed verbally?  How are you going to read #T and
() aloud (e.g. in class, or when helping a user over the phone)?  I
claim the best pronunciation of () is probably the funny two-toned bleep
used by the Star Trek communicators, but I am unsure how to get it in
class.  In fact, if you end up with 2A and 2, which seem the most likely
"compromises", people are going to end up reading #T and () as "t" and
"nil".  That is fine as long as no one actually uses T and NIL as if
they were normal atoms.  But if they do, imagine talking (or thinking)
about a program that had a list (NIL () () NIL).

By the way, if you do decide to use proposal 1 for NIL, please consider
disallowing NIL as a function.  It seems that it is going to be worse
for us to allow NIL as a function than to implement property lists or
other attributes.
-------