What are you missing? and "patching" ATOM and LISTP

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

  Date:  2 Mar 1982 1658-EST
  From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
  Subject: I think I am missing something
  . . .
The reasons for distinguishing NIL from () aren't related to the GET
problem mentioned in your note;  RMS mentioned this too in his note
of Mar 3.   In fact, since Common-Lisp will have multiple-values, the
only sensible solution for GET (and others like it, such as the HASH-GET
I have in a hashing package) is to return two values, the second of which
tells whether or not the flag/attribute was found.

A more important aspect is the potential uniformity of functions which
act on lists -- there needn't be a split of code, one way to handle
non-null lists, and the other way to handle null (e.g. CAR and CDR).
In fact, I think RMS's statement of the problem on Mar 1 is quite succinct,
and bears repeating here:
    Date: 1 March 1982 23:43-EST
    From: Richard M. Stallman <RMS at MIT-AI>
    Subject: () and T.
    I believe that () should be distinuished from NIL because
    it is good if every data type is either all true or all false.
    I don't like having one symbol be false and others true.
    Another good result from distinguishing between () and NIL is
    that the empty list can be LISTP. . . .

However, even though it would be reasonable for CONSP to return its argument
when "true", I don't believe there is advantage to having predicates like
ATOM and LISTP to try to return some "buggered" value for null.  There has to
be some kind of discontinuity for any predicate which attempts to return its
argument when "true", but which is "true" for the "false" datum;  that
discontinuity is as bad as CAR and CDR being applicable to one special symbol
(namely NIL).  The limiting case in this line of reasoning is the predicate
NOT -- how could it return its argument?  Patching ATOM and LISTP for the
argument of "false" makes as much sense to me as patching NOT.