Several comments Michael Burschik (08 Apr 2003 10:30 UTC)
|
Re: Several comments
Taylor Campbell
(08 Apr 2003 12:04 UTC)
|
AW: Several comments
Michael Burschik
(08 Apr 2003 12:50 UTC)
|
Re: Several comments
David Rush
(23 Apr 2003 08:44 UTC)
|
AW: Several comments
Michael Burschik
(23 Apr 2003 09:07 UTC)
|
Several comments Michael Burschik 08 Apr 2003 10:29 UTC
I do not believe in providing library functions for arbitrary special cases that might all be expressed in terms of a single more general function. In fact, I consider this attitude to be one of the great differences between Scheme and Common Lisp. Several of the comments below are biased by this conviction. 4.1 Constructors The function vector-iota is simply a not particularly interesting special case of the function vector-tabulate. Is the desire to mimic SRFI-1, which in turn is inspired by APL, sufficient to introduce this function? 4.2 Predicates Is the pathological case of a vector with no elements really common enough to warrant the introduction of two predicates that could be implemented in terms of vector-length? Lists and vectors are pretty different in this regard. 4.3 Accessors While first, second, etc. are certainly more legible than car, cadr, etc., this does not apply to vector-first and friends, which are simply not-so-short shorthands for (vector-ref vec index). Indeed, since the indices of vectors are zero-based, the ordinals might even be considered misleading. Of course, this also applies to list-ref, but referring to list elements by index seems to be less common in the lisp community. The vector-take and vector-drop functions are all variations of a single theme, namely selecting a sub-vector, and could all be replaced by the function vector-copy, defined as a constructor in section 4.1. In this regard, vector-copy is more powerful than the function list-copy defined by SRFI-1. 4.4 Miscellaneous I am not sure whether the limitations of some scheme implementations with regard to the length of argument lists should enter into the definition of a SRFI. If it should not, the function vector-concatentate* is simply superfluous, and even if it should, the function is inappropriately named, as the asterisk usually implies left-to-right evaluation rather than a certain argument type. Nor is the name of the function vector-zip very helpful, as "zipping" usually refers to some kind of compression. And again, is all this "unzipping" really common enough to warrant the definition of five additional functions? And yes, this also applies to SRFI-1. 4.5 Iterators If vector-unfold is the fundamental vector constructor, it should be defined in 4.1 and not 4.5. Moreover, vector-unfold is hardly a suitable name for a constructor. As the function is similar to "do" returning a vector, the syntax might be changed to reflect this similarity. On the other hand, this would break the similarity to SRFI-1. Given a not too inefficient implementation of vector-reverse, which should be possible, the whole issue of left/right iteration would seem rather pointless. 4.9 Association Vectors Who needs association vectors in addition to association lists and hash tables? What are their advantages? Or is a strict translation of SRFI-1 the main motivation for their definition? Disclaimer: I realize that many of the names shadow those introduced by SRFI-1, but that does not necessarily make them any better.