[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
truth of '()
Date: Tue, 31 Jan 89 18:39:37 PST
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''.
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.