'everything is a list' as a separate issue Sergei Egorov 20 Feb 2099 01:47 UTC
>From: Olin Shivers <firstname.lastname@example.org>
Date: Saturday, February 20, 1999 3:17 AM
>Yes, this is a good point. If you have the notion that everything is a
>then any procedure named LIST? that isn't (LAMBDA (X) #t) is probably going
>to cause some confusion. This is exactly why my "Everything is a list"
>msg proposed these three predicates, which *aren't* misleading in this
> circular-list? x -> boolean
> proper-list? x -> boolean
> dotted-list? x -> boolean
>IMPROPER-LIST? is a perfectly fine thing. It's either of these:
> (conjunction circular-list? dotted-list?)
> (negate proper-list?)
>Given that PROPER-LIST? exists, is it important to define IMPROPER-LIST?
>Just to reiterate, I am now proposing to punt LIST? for exactly this
>in favor of PROPER-LIST?, CIRCULAR-LIST?, DOTTED-LIST?.
I see your point, but it still doesn't convince me that accepting dotted
lists everywhere is a right thing to do. Here are some things that make me
feel uncomfortable with this idea:
1) ANSI Scheme and all revisions of the Report defined a term 'list' as
'either the empty list or a pair whose cdr is a list'. All standard list
were defined accordingly and most implementations do the neccessary
error checking as encouraged by the report.
2) from my experience, improper and circular lists rarely occur in practice
compared to proper lists. Considering proper lists a ''special case" of
dotted lists is technically correct, but feels like tail wagging the dog:
simple and common things pay for more complex and rare things if
not in terms of performance then in terms of 'learning curve'.
3) many common mistakes like (member list object) will go unnoticed; most
function will never signal a domain error no matter what arguments they are
This is not OK in dynamically-typed language where significant percentage of
calculations deal with lists.
4) for some people the 'learning curve' might end the moment they see
something like (length "hello") = 0
Maybe it's just me. In any case, I think this issue can be separated from
the main body of SRFI-1 discussion by introducing CL-like end? predicate
defined as follows:
(end? x) returns #t for the empty list and #f for pairs. Its behavior on
other objects is unspecified (by this SRFI).
The behavior of all SRFI-1 procedures may be defined using end? as a list
termination condition. There could be several (conflicting) SRFIs specifying
exactly what happens when end? is applied to atoms. Then both implementors
and users will have a choice...