Re: Several comments Taylor Campbell 08 Apr 2003 12:04 UTC
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.