This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
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