This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
From: Olin Shivers <shivers@xxxxxxxxxxxxxxxxxx> Date: Saturday, February 20, 1999 3:17 AM >Yes, this is a good point. If you have the notion that everything is a list, >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 >context: > 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 reason, >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 functions 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 list function will never signal a domain error no matter what arguments they are fed. 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... Sergei Egorov