truth of '()

[mkatz@sesame.Stanford.EDU (Morris Katz)]

   Date: Tue, 31 Jan 89 18:39:37 PST
   From: Pavel.pa@Xerox.COM

   I certainly support unspecifying the truth-value of the empty list.  Unlike
   Ken Dickey, I don't feel the need for an immediate change to specifying
   that () is true, either.  I'm perfectly willing to give implementations one
   more bounce of the report to get switched over.

   Morry Katz is strongly in favor of unspecifying the truth-values of
   non-booleans.  This has never appealed to me.  Morry, could you provide
   more extensive support for your view that the ``resulting code would ... be
   much easier to read and less error prone''?  I'm not convinced that the
   status quo in this case is an example of ``traditionally poor semantics''.

	   Pavel


Currently, there are a lot of functions that do things like return a list or
nil, if no match is found.  I think that it would be much clearer to the reader
if such a function were wrapped in a call to NULL? when used as a predicate.
Similar use of PAIR?, etc. forces the programmer to specify the types of values
he/she expects the given function to return and consequently informs the reader
of this information.  I find such code mush easier to read.  Maybe this is just
my hangup, but the use of all objects as boolean values seems to me a little
like a type error.  My personal perspective is that asking whether '() and #f
are eq? is a little like asking whether (char? 13) returns #t.  Types should
really be disjoint and this includes the boolean values #t and #f.
					Morry Katz
					katz@polya.stanford.edu