Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!decwrl!labrea!csli!johnson
From: johnson@csli.STANFORD.EDU (Mark Johnson)
Newsgroups: comp.lang.lisp
Subject: Overloading of NIL (as empty list and logical falsity)
Summary: Is it a good idea?
Message-ID: <8247@csli.STANFORD.EDU>
Date: 22 Mar 89 17:54:57 GMT
Sender: johnson@csli.Stanford.EDU (Mark Johnson)
Reply-To: johnson@csc.brown.edu (Mark Johnson)
Distribution: na
Organization: Cognitive and Linguistic Sciences, Brown University.
Lines: 40


I was writing a couple of demo unification programs recently
and the situation arose where I wanted the unification function
to return either a value indicating failure (of unification) or
a variable substitution (i.e. a list of pairs).

The problem is that NIL could conceivably mean both failure of
unification (i.e. FALSE) and also the empty variable substitution.
I know how to get around this problem, but it struck me that
maybe the overloading of the symbol NIL as both logical falsity
and also the empty list as is common in Lisp might not be such a 
good idea.

I know that texts like Winston and Horn tout this as an advantage,
but I'm not so sure.  If () was distinct to NIL (= FALSE) then
my little unifier would be a lot clearer to read.

Of course, some list manipulation programs would be more complex.
For example, instead of writing

(defun my-member (elt list)
  (and list
       (or (equal elt (first list))
           (my-member elt (rest list)))))

I would have to write

(defun my-member (elt list)
  (and (non-null list)                    ; or better (consp list)
       (or (equal elt (first list))
           (my-member elt (rest list)))))

Of course the second version actually expresses more precisely what
I mean: list is not a logical value, so it really isn't an appropriate
argument to a boolean function.

Does anybody else have any comments on the matter?  Do more advanced
functional languages (ML?) incorporated the same overloading of NIL?

Mark Johnson.