This page is part of the web mail archives of SRFI 43 from before July 7th, 2015. The new archives for SRFI 43 contain all messages, not just those from before July 7th, 2015.
On Tuesday, April 8, 2003, at 06:29 AM, Michael Burschik wrote:
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?
If I receive several more arguments against it, and not enough matching arguments for it, then I'll take it out.
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.
VECTOR-NONEMTPY?, I suppose, really is a little pointless, but VECTOR-EMPTY? can be useful to pass to other functions, and I also desired to keep it for congruency with Scott G. Miller's upcoming collection SRFI (though now *-EMPTY? has turned into COLLECTION-EMPTY?, and I don't know if he's going to change
it...just wait and find out).
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.
VECTOR-FIRST/SECOND/... were designed pretty much just to pass to other functions as arguments (instead of the more cumbersome(lambda (vec) (vector-ref vec 0/1/2...)), much like XCONS from SRFI 1, but again, if there are more arguments against it than arguments for it, I'll go and
take it out.
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.
Yet again, if there are more arguments against than for, I'll remove them.
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.
And yet again, if there are more arguments against than for, I'll remove them.
I don't really have an opinion on this myself -- I just thought it might be
useful to concatenate a list of vectors instead of calling APPLY on VECTOR-APPEND. The fact that some Schemes have a limitation
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.
Considering that SRFI 1, libraries of Haskell, libraries of OCaml, and several other libraries use the term 'zip' and 'unzip,' I think I'll leave it with that
-- and anyways, can you think of a better term?
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.
VECTOR-UNFOLD[-RIGHT] were included pretty much only because STRING-UNFOLD[-RIGHT] were included in SRFI 13, actually.But yet again, if there are more arguments against than for, I'll remove it.
Given a not too inefficient implementation of vector-reverse, which should be possible, the whole issue of left/right iteration would seem rather pointless.
More arguments against than for -> deletion.
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?
At first it was just a translation of alists from SRFI 1, and I was considering removing them entirely, but Scott G. Miller was against this -- his argument being that they took up much, much less space than either hash tables or alists
-- and so, having a bit better of a reason to keep them, I kept them.
Disclaimer: I realize that many of the names shadow those introduced by SRFI-1, but that does not necessarily make them any better.