This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 are here. Eventually, the entire history will be moved there, including any new messages.
From: "Sergei Egorov" <esl@xxxxxxxxxxxxxxx> Date: Tue, 10 Aug 1999 15:42:57 -0400 I have several comments on the final draft: - NULL-LIST? is allowed to handle circular lists in the first sentence of its description and disallowed in the third. Taking into account the intended use of circular lists in MAP-like functionals, I think that it is logical to allow NULL-LIST? to return #f on circular lists (?) Oops -- that's a typo. NULL-LIST should indeed return #f on circular lists. I have added the starred text: "It is an error to pass this procedure a value which is not a proper *or circular* list." - TAKE, TAKE-RIGHT: I am still not convinced that "the last 2 elements of (1 2 3 . d) " are (2 3 . d) and that in this case the benefits of extended arguments domain overweight error checking. Scheme's LIST-TAIL does not handle dotted lists (inspite of the fact that its sample implementation won't notice the difference) and I believe there's no *immediate* need to allow dotted list handling in TAKE/DROP. This is also true for LIST-COPY and LAST (I can agree that (last-pair '(1 2 . 3)) is (2 . 3) but the fact that (last '(1 2 . 3)) is 2 still looks like an oddity). - It's a completely consistent view. - It preserves the important identities (append (take x i) (drop x i)) = x (append (take-right x i) (drop-right x i)) = x - It's driven by the view of DROP as simply being cdr^n. (This is discussed in the Common Lisp rationale.) - Searching: the criteria of acceptability of arguments to a search procedure based on the result of the search itself (circular lists) is very confusing and contradicts the traditional notion of "argument types": acceptability of an argument should be judged using universal rules ("types" or "domains") and should not depend on values or types of other arguments. This approach simplifies documentation and understanding of the procedure's behavior; it also serves as a basis for formal type systems, both "soft" and static. That is *my* opinion, as well, but you guys overrode me. There is no "proper list" type in Scheme! So it does not make sense to restrict these functions to proper lists -- i.e., to throw out dotted lists. The dynamic typing of Scheme means that in order to strictly enforce such a ban, you would have to have your search procedure search all the way to the end of the list to check termination, even if the element being sought was the first or second element. But I bow to the public voice, and spec these procedures restricting them to patterns of data structure that are not part of the underlying type system. Circular lists are a perfectly useful data structure; they fit some algorithms ust right. Allowing you to pass cirular lists to FIND-TAIL allows you to "rotate" a list, which is handy. I do not feel this is a squirrel case. As a general note, the list library design process demonstrated weakness of the Scheme lists concept. It is not a "stable" feature that resists all attempts to revise it; some of the revisions are even useful in some situations, and all the messy details can be carefully documented (see the CL spec). But original description of lists as finite and NULL-terminated sequences of pairs, even in its present "unstable" form, is the simplest design choice that covers all common uses. Yes, that's a good summary. But I would like to cover the uncommon cases, as well, where possible. I know that the chances to convince Olin so lately in the design process are close to nothing, but given the amount of work that went into this SRFI it's still worth a try... Sergei, as always, I appreciate your careful reviews and comments. -Olin