From: Bob Riemenschneider
Subject: Overloading of NIL (as empty list and logical falsity)
Date:
Message-ID: <8903222013.AA00234@zooks.ads.com>
=> 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. ...
Scheme avoids the complexity by counting () as false, in the same sense
that Common Lisp treats everything other than () as true. (But R3RS allows
#f and () to be identical, so not every dialect provides a solution to your
original problem.)
-- rar
From: J A Biep Durieux
Subject: Re: Overloading of NIL (as empty list and logical falsity)
Date:
Message-ID: <2220@ski.cs.vu.nl>
>If () was distinct to NIL (= FALSE)
> then my little unifier would be a lot clearer to read.
But why does your empty list have to be NIL? let your bindings-list
end in T, and the problem is gone:
NIL --> unification failed
T --> unification succeeded with empty set of bindings
(--- . T) --> unification succeeded with given set of bindings
If your programs test for end-of-list with (ATOM &) instead of with
(NULL &), then everything should work OK.
After all, ending lists with the symbol for FALSE is only a choice,
not something imposed upon you by the language (except by the print-
functions, maybe..)
--
Biep. (ยทยทยทยท@cs.vu.nl via mcvax)
Who am I to doubt the existence of God? I am
only a simple man, I already have trouble
enough doubting the existence of my neighbour!