[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

disjointness of '() and #f



   Date: Wed, 14 Feb 90 19:05:47 est
   From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
   Reply-To: jinx@zurich.ai.mit.edu

   As a convention, we build lists on top of them by distinguishing some
   arbitrary object as the end of all lists and the empty list.  I don't
   advocate for this distinguished object to be #f, I just don't want you
   to force me to have a magic object just for this purpose.  #f happens
   to be a convenient such object to choose.  It is only a convention
   that can be violated at any time.

#F happens to be a very INconvenient such object to choose, because
historically it has been identified as the one and only object that is
the empty list.  This leads to the punning we are all familiar with,
and which disjointness is designed to eliminate.

Suppose your Lisp system selected an object "at random" to be the
empty list each time it was started.  Sometimes it would be the number
239, sometimes it would be a procedure (lambda () #t), sometimes it
would be the symbol NIL, sometimes it would be #F.  Once selected at
startup it would never change, but you would have no way of predicting
what value it would take.  There is no magic object that is the empty
list.  Would this arrangement be satisfactory to you?  (Let's ignore
the cost of implementing it.)  What is the interesting difference
between this world, and the "unique empty list" world?  In fact, the
unique empty list world looks like the asymptotic limit of the "Queen
for a Day" world, and much easier to implement!

One of the functions of Scheme in the world of Lisp (not to mention of
standardization in general) is to codify and rationalize conventions.
As a convention, we represent boolean values by distinguishing some
arbitrary object as falsehood.  NIL happens to be a convenient object
to choose.  On further reflection, we choose two objects distinct from
all others, #T and #F, to represent truth and falsehood.  As a
convention, we represent functions as lists whose CAR is the symbol
LAMBDA.  On further reflection, we create a new data type distinct
from all others to represent functions.