From: John Cowan
Subject: Re: FALSE vs empty list
Date: 
Message-ID: <26E7C356.5DE7@marob.masa.com>
In article <·······@otter.hpl.hp.com>,
	···@otter.hpl.hp.com (Steve Knight) writes:
>The type-distinctness of empty-list and false in a Lisp or Lisp-like
>language is an aesthetic consideration.  Many folks, and I'd include myself,
>believe that making them distinct is more convenient and makes programs
>more readable.  Ultimately, our arguments must boil down to "I don't think
>of an empty list and false in the same way.  I don't think that applying
>boolean operators to lists makes good programming practice." and so on.

Something that Lispers never seem to address, but is the case in Smalltalk,
is the distinctness of the empty list and the undefined datum.  In Smalltalk,
nil, false, and () are completely different: they have different types.
I find this to be extremely useful.

For example, this neatly solves the problem of representing the difference
between knowledge of nothing and ignorance.  () represents knowing that
something has no elements, whereas nil represents ignorance.  This solves
the problem of returning a list of bindings vs. returning failure.

Is there any dialect of Lisp in which such a distinction is made?  I know
that Scheme optionally distinguishes between #f (false) and '() (the empty
list), but does anyone distinguish between #f, '(), and #nil, or the like?
-- 
·····@marob.masa.com			(aka ...!hombre!marob!cowan)
			e'osai ko sarji la lojban
From: Larry Masinter
Subject: Re: FALSE vs empty list
Date: 
Message-ID: <MASINTER.90Sep8084957@origami.parc.xerox.com>
> In article <·······@otter.hpl.hp.com>,
> 	···@otter.hpl.hp.com (Steve Knight) writes:
>The type-distinctness of empty-list and false in a Lisp or Lisp-like
>language is an aesthetic consideration.  Many folks, and I'd include myself,
>believe that making them distinct is more convenient and makes programs
>more readable.  Ultimately, our arguments must boil down to "I don't think
>of an empty list and false in the same way.  I don't think that applying
>boolean operators to lists makes good programming practice." and so on.

I think it was David Moon that characterized this (in 79?) as
something that some people consider to be a wart on the face of Lisp,
but others think of it as a beauty mark.

Personally, I always found the pun of NIL and false and () to be much
more of a convenience than a hinderance, but styles and preferences in
programming languages do vary. That 0 and false and end-of-string are
the same in C sometimes annoys me.


>In article <·············@marob.masa.com> ·····@marob.masa.com (John Cowan) writes:
> Something that Lispers never seem to address, but is the case in Smalltalk,
> is the distinctness of the empty list and the undefined datum.  In Smalltalk,
> nil, false, and () are completely different: they have different types.
> I find this to be extremely useful.

> For example, this neatly solves the problem of representing the difference
> between knowledge of nothing and ignorance.  () represents knowing that
> something has no elements, whereas nil represents ignorance.  This solves
> the problem of returning a list of bindings vs. returning failure.

> Is there any dialect of Lisp in which such a distinction is made?  I know
> that Scheme optionally distinguishes between #f (false) and '() (the empty
> list), but does anyone distinguish between #f, '(), and #nil, or the like?

Something like this was proposed for Common Lisp: the idea that there
would be a distinct value "undefined". The discussion got tied into
knots about what it would mean to store "undefined" in a variable, how
could you say in a program that a value *should be* undefined without
getting errors because you were trying to use an undefined value,
etc., to the point where there was nothing we thought we could add to
the language that would reasonably automatically detect uses of
undefined values.  Besides, in many situations there are multiple
degrees of uncertainty ("undefined, but I know it is a number > 0",
"undefined symbol").




--
Larry Masinter (········@parc.xerox.com)
Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road; Palo Alto, CA USA 94304
Fax: (415) 494-4333