[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: T and NIL
- To: FAHLMAN at CMU-20C
- Subject: Re: T and NIL
- From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
- Date: Mon, 01 Mar 1982 16:11:00 -0000
- Cc: common-lisp at SU-AI
- In-reply-to: Your message of 28-Feb-82 1500-EST
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