From: "Sergei Egorov" <xxxxxx@informaxinc.com>
   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