[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-1 final draft available
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.