[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Several comments




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.