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.