[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NIL versus (), and more about predicates.
- To: Fahlman at CMU-10A
- Subject: NIL versus (), and more about predicates.
- From: Jon L White <JONL at MIT-MC>
- Date: Tue, 02 Mar 1982 18:28:00 -0000
- Cc: common-lisp at SU-AI
NIL and ()
RMS just raised up several important points about why it would
be worth the effort to distinguish the empty list from the symbol
NIL. Some years ago when the NIL effort addressed this question,
we felt that despite **potential** losing cases, there would be
almost no effort involved in getting existing MacLISP code to
work merely by binding NIL at top level to (). GJC's comments
(flaming aside) seem to indicate that the effect of this radical
change on existing code is indeed infinitesimal; the major problem
is convincing the unconvinced hacker of this fact. I've informally
polled a number of LISPMachine users at MIT over the last year on
this issue, and the majority response is that the NIL/() thing is
unimportant, or at most an annoyance -- it pales entirely when compared
to the advantages of a **stable** system (hmmm, LISPM still changing!).
Return value of Predicates:
However, we didn't feel that it would be so easy to get around
the fact the function NULL is routinely used both to test for the
nullist, and for checking predicate values. That seems to imply that
the nullist will still have to do for boolean falsity in the LISP
Boolean truthity could be any non-null object, and #T is merely a
way of printing it. As long as #T reads in as the canonical truth
value, then there is no problem with existing NIL code, for I don't
believe anyone (except in a couple of malice aforethought cases)
explicitly tries to distinguish #T from other non-null objects.
Certainly, we all could live with a decision to have #T read in as T.
But note that if #T isn't unique, then there is the old problem, as
with NIL and () in MacLISP now, that two formats are acceptable for
read-in, but only one can be canonically chosen for printout; it would
thus be *possible* for a program to get confused if it were being
transported from an environment where the distinction wasn't made into
one where it was made.
Most "random" predicates in PDP10 MacLISP (i.e., predicates that
don't really return any useful value other than non-false) return the
value of the atom *:TRUTH, rather than a quoted constant, so that it is
possible to emulate NIL merely by setq'ing this atom.
At the Common-LISP meeting last November, my only strong position
was that it would be unwise *at this point in time* to commit "random"
predicates to return a specific non-false value (such as the symbol T).
The reason is simply that such a decision effectively closes out the
possibility of ever getting a truthity different from the symbol T -- not
that there is existing code depending on #T. Had the original designers
of LISP been a little more forward-looking (and hindsight is always better
than foresight!) they would have provided one predicate to test for nullist,
and another for "false"; even if one particular datum implements both,
it would encourage more "structure" to programs. I certainly don't feel
that the nullist/"false" merger can be so easily ignored as the nullist/NIL
The T case for CASE/SELECT is unique anyway -- the T there is unlike
the T in cond clauses, since it is not evaluated. This problem
would come up regardless of what the truthity value is (i.e., the
problem of the symbols T and OTHERWISE being special-cased by CASE)