Comments on SRFI-1.

["Harvey J. Stein" <hjstein@xxxxxxxxx>]

I'd like to make a few comments on SRFI-1.

I'm not subscribed to SRFI-1, so please Cc me on any discussion on
these points, but judging from the volume of traffic in the mailing
list repository there won't be so much (which is why I'm also mailing
my comments to the author).  In any case, I'll check the mail archive
every now and then to see if anything's happening.

I. Function addition - list-length>=?

First of all, I'd like to suggest adding a function.  I often find
myself having to write code like:

   (if (>= (length l) 3)
       (do something with (list-ref l 2)))

I guess this sometimes comes from processing the rest variable in
funtions defined like (lambda (x y . rest) ...), but it also arises in
other contexts.

This has the ugly performance of hit that it takes O((length l))
instead of O(position being tested).

So, may I suggest adding:

   list-length>=? l n -> #t/#f

   Returns #t iff (>= (length l) n)

This has the obvious implementation:

   (define (list-length>=? l n)
      (if (<= n 0)
          0
          (list-length>=? (cdr l) (- n 1))))


II. .iota & iota..

I also felt the same way as Sergei Egorov <esl@xxxxxxxxxxxxxxx> when I
first read about .iota & iota., namely that the names are less than
ideal in that they're problematic identifiers, unclear which side is
open & funny looking.  I also agree that optional argument handling is
strange, although I think that it does make sense for this particular
function & it is under common usage (I assume the apl usage is
similar, & xlispstat has iseq which has the same behavior).

I also don't see why half open intervals are so important - I'd think
that if you're going to include functions for generating left open &
right open intervals that you should also include closed & open
intervals.

III. take & drop.

Again, I agree with Sergei that it is strange to count from the end
when the index argument is negative.  Does anyone have any examples
where this would be much more convenient than having 2 sets of fcns -
one for counting from the beginning & one for counting from the end?
I don't see any continuity reasons for thinking that (take l -1)
should be a list containing the last element of l.

It also gives a funny overlap between take & drop - (take l n) = (drop
l (- n (length l))), or some such thing.  

IV. unfold & unfold/tail

This is just a documentation issue.  I think it'd be easier to
understand the spec if the names of the arguments to unfold were more
descriptive.  For example, maybe change:

   unfold p f g seed -> list

to something like:

   unfold stop-seed? seed-map next-seed first-seed -> list

   Keeps applying next-seed recursively until it returns a seed for
   which stop-seed? returns #t.  Returns the list of values returned
   by seed-map called on the seeds produced.

V. General comment.

I'd like to see more uniformity in calling conventions.  I realize
that it's hard to balance convenience, efficiency, and generality
while trying to keep the number of fcns small, but I think for a
library it's better to err on the side of more fcns to get the
necessary generality (with similar enough names to make remembering
them easier) and efficiency than for convenience (as in the use of
optional arguments or using numerical sign to denote things).  I agree
it's difficult & I'm not so sure I'd be able to improve the list
library a lot, but things which seem to stick out in my mind are
things like .iota & iota. vs unfold & unfold/tail.  I agree that each
one is natural, but it seems to me that the two together lack
uniformity.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@xxxxxxxxx