[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.