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 Thursday, April 10, 2003, at 04:20 AM, Sergei Egorov wrote:
I completely agree with all "remove this" comments made by Michael Burschik.
As do I -- I just made it very large initially to accommodate the desires of everyone, and then cut down everything undesirable. I expected when I wrote it
that it would be at most two thirds of its original size when (if) it's finalised.
<Flame>
Flame? It doesn't look very inflammatory to me...
I think that most of the operations that generate vectors element-by-element are useless, especially when the performance is the same as in making a listfirst and then turning it into a vector.
There are two if these -- VECTOR-UNFOLD and VECTOR-UNFOLD-RIGHT -- unless there were some more that somehow escaped my notice and I-search's notice in Emacs when I searched for any usage of LIST->VECTOR and VECTOR->LIST in the reference
implementation, in places other than where they're defined.
The reason for the existence of vectors is constant-time access by index and smaller memory footprint; everything else is better done with lists. Having one humongous SRFI for lists pretty much solves the problem; there is no need to replicate it for every "linear" data structure. What Scheme needs is more orthogonality, not less, and this SRFI (together with large part of Olin'sstring-lib) just adds more names, not more functionality. Orthogonal approach is to abstract over the concept of "sequence"
This is what Scott G. Miller's upcoming SRFI plans to implement. I think you'll
probably like it -- not only does it define operations on the concept of 'sequences' but also other various sorts of collections (bags, sets, dictionaries, et cetera).
(this is not the same as giving "generic" versions of all the functions with switch by pair? / string? / vector?) and have a good SRFI for high-order functions like COMPOSE, NEGATE, CURRY, BIND, etc.
What does BIND do?And if you'd like a SRFI of that sort, I'd be happy to try and write one up.
Only in places where sequences are different from each other do we need new functions; in case of vectors, they support effective direct access to / modification of content. I suggest to drop everything that is not related to the main purpose of vector's existance: constant-time indexed access. Here's what I would left (in addition to what's already in Scheme): vector-tabulate
OK.
vector-copy!
I'm OK with this one, but what about VECTOR-COPY? (the non-destructive version)
vector-append
If there is to be an appending operation, then I think it should be either VECTOR-CONCATENATE or VECTOR-CONCATENATE* (the latter of which operates on lists (if you can think of a better name, feel free to), and which lets you do what you might otherwise do with APPLY and VECTOR-APPEND. I would avoid using the APPLY and VECTOR-APPEND solution because not only would VECTOR-APPEND be
trivially implemented with VECTOR-CONCATENATE* (and is in the referenceimplementation) but it also avoids the restriction of numbers of arguments in
some implementations).
vector-reverse!
If there is to be a VECTOR-REVERSE!, I think there should also be a non-destructive VECTOR-REVERSE.
vector-fold{-right}
I agree with these, but I'd like to possibly also see VECTOR-REDUCE[-RIGHT], unless there's a compelling reason not to have it. (the reason -to- have it is
that it's much faster if it's applied to the empty vector)
vector-unfold{-right}
Are these really necessary? I only included them in the SRFI because they were in both SRFIs 1 and 13, though I am vaguely against them only for the reason that it's hard to implement them more efficiently than with UNFOLD (the list version) and LIST->VECTOR. They're also against the idea of vectors, which is because they produce vectors of a size that isn't known when they're called.
vector-map! vector-map/index!
Non-destructive versions?
vector-for-each{-right}
vector-index{-right}
vector-skip{-right}
OK.
vector-fill! ;extended version
'Extended' meaning the one that takes START and END arguments? If so, I'm OK
with that, too.
</Flame> It would also be nice to have in-place versions of insert/delete where insert drops elements off the tail while delete shifts in an (optional) new value.
Are there really that many situations in which you would want insert and delete
operations of that sort?
Left/right and circular shifts are also useful.
This sounds useful enough to me.
-- Sergei
What do you think about vector operations taking any number of vectors or START
and END arguments, by the way?