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.
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 (?) - It seems to me that UNCONS is a better name for CAR+CDR; it does not imply addition and this naming convention can be extended to reverse versions of other constructors (UNLIST, UNVECTOR etc.) - 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). - 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. 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. I don't think that it is possible to change Scheme's approach to what constitutes a "list" without either compromising dynamic type checking or complicating static type checking. Fortunately (at least that's my feeling), improper lists and circular list are not essential and not commonly used (I consider circular arguments to MAP as kludges that should have zero effect on language design). My radical proposal is to remove all references to dotted and circular lists from the library specification and leave the possibility to extend the spec via the "it is an error" statements. 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... Regards, Sergei