Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!glacier!jbn
From: jbn@glacier.STANFORD.EDU (John B. Nagle)
Newsgroups: comp.lang.lisp
Subject: Re: Overloading of NIL (as empty list and logical falsity)
Message-ID: <18207@glacier.STANFORD.EDU>
Date: 23 Mar 89 06:19:02 GMT
References: <8247@csli.STANFORD.EDU> <9840@megaron.arizona.edu> <37807@think.UUCP>
Sender: John B. Nagle <jbn@glacier.stanford.edu>
Reply-To: jbn@glacier.UUCP (John B. Nagle)
Distribution: na
Organization: Stanford University
Lines: 24

In article <37807@think.UUCP> barmar@brigit.think.com.UUCP (Barry Margolin) writes:
>Common Lisp, a popular approach is to return two values -- the first
>is the value, and the second indicates whether the first is a list or
>boolean when it is NIL.

      Yes, although multiple-return-valued functions are decidedly an
afterthought in CL.  Mesa is one of the few languages to integrate
this notion well.

>I think most language theorists would now agree that Lisp's
>overloading of NIL was a bad idea.  I don't think any non-Lisp-like
>languages copy this.

      C's notion that conditionals test for nonzero integer values
follows this line of reasoning.  The result in C is that programs 
are slightly shorter, somewhat more likely to be in error, and no
more efficient because of it.

      In strongly typed languages, such as Pascal and its descendants,
the notion that NIL is a component of all pointer types is sometimes
troublesome.  But the alternative, a NIL for every type, seems so
nit-pickey.

					John Nagle