NIL versus (), and more about predicates.

[Jon L White <JONL at MIT-MC>]

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
  world.

  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
  merger.

  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)