Subject: Re: On nil qua false [was: Re: On conditionals]
From: Erik Naggum <>
Date: Thu, 22 Nov 2001 01:55:15 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Thomas F. Burdick
| Do you consider (not (zerop ...)) to be a double negative?

  That depends on how you use it.  I prefer (/= 0 ...) to duoble predicates.

| But, yes, my first reaction to your code above is that FIND returns a
| boolean.  Really, it returns a list.

  But find _does_ return nil or the object you asked it to find.  It does
  _not_ return a list, because it _cannot_ return a cons unless you have
  asked it to find a cons, which is a statement about the specific call,
  not about the function in general.  (Functions like this that return nil
  or cons are member and assoc.)  The function position also returns nil or
  the position where it found something, not a cons, so its notion of true
  is simply "non-nil".

  I maintain that it would not make sense to make nil or () not be false
  without making every other object also not be true.  If punning on false
  is bad, punning on true is also bad.  If we have a pure boolean type, we
  would need to rethink this whole return value business and consider pure
  predicates, not just for things like null to see if a list is empty, but
  it would also be wrong to give it a non-list.  So this is not a question
  just of (not (null ...)), but of (and (listp ...) (not (null ...))),
  which is again what (consp ...) does more efficiently, so the whole (not
  (null ...)) thing is kind of moot.  It works today _because_ of the pun
  on true and false.  It would not make sense to use null on non-lists in a
  strict boolean-type universe, because boolean would not be the only type
  to be treated anal-retentively.

| So the body of your WHEN is being run when FIND returns a non-empty list,
| not when it returns true.

  I think you should look up what find does and returns, now...

| Imagine recasting it numerically:
|   (when (not (zerop (count long-sought-thing input-stuff)))
|      (do-stuff))
| if that had been:
|   (when (count long-sought-thing input-stuff)
|      (do-stuff))
| you would assume that COUNT was a predicate.

  But this carefully elides the context in which nil = () = false makes
  sense.  In a language where you return pointers or indices into vectors,
  0 = NULL = false makes sense.  In such a language, you could not have a
  function position that returned the position where it found something,
  because 0 would 

| No, my position is that there's a conceptual difference between the empty
| list (), and the boolean false NIL.  And that it's kinda weird that false
| is a symbol.

  Since there _is_ no "false" concept as such, but rather "nothing" vs
  "thing" that supports a _generalized false_, I think the conclusion only
  follows because you think the type boolean is defined differently than it
  is.  In fact, the boolean type is defined as the symbols t and nil.
  (Please look it up in the standard.)

| None of this causes me much of a headache, though, and it's usually a
| difference of a half a second or less to figure out that someone meant
| false, not ().

  I think this betrays a conceptual confusion.  If you realized that they
  are in fact exactly the same thing, you would not need to think about it,
  but since you think they are something they are not, it takes think time
  to undo the confusion.  It is much smarter to fix the confusion at its
  core and realize that you you cannot get what you want because what you
  want is not within the tradition that produced Common Lisp.

  Norway is now run by a priest from the fundamentalist Christian People's
  Party, the fifth largest party representing one eighth of the electorate.
  Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.