Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!rutgers!rochester!pt.cs.cmu.edu!pt!clamen From: clamen@CLAMEN.CS.CMU.EDU (Stewart Clamen) Newsgroups: comp.lang.lisp Subject: Re: Overloading of NIL (as empty list and logical falsity) Message-ID: Date: 23 Mar 89 06:20:09 GMT References: <8247@csli.STANFORD.EDU> Distribution: na Organization: Carnegie Mellon University Lines: 36 In-reply-to: johnson@csli.STANFORD.EDU's message of 22 Mar 89 17:54:57 GMT In article <8247@csli.STANFORD.EDU> johnson@csli.STANFORD.EDU (Mark Johnson) writes: 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. .... 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? The empty-list/false "feature" in LISP is more of a pun in my opinion than anything else. In the Scheme world, we are slowly moving away from it. The current Standard does not require that #f (the false object) and () (the empty list) be synonymous, and at a recent meeting, the issue of actually having the empty-list be non-false (ie. returning #f from (NOT ()) !), was even raised. -- ------------------------------------------------------------------------------ Stewart M. Clamen School of Computer Science, Carnegie Mellon University Pittsburgh, PA 15213-3890 INTERNET: clamen@CS.CMU.EDU USENET: ...!uunet!"clamen@cs.cmu.edu" --