[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Too much of a good thing?
On Thursday, April 10, 2003, at 04:20 AM, Sergei Egorov wrote:
I completely agree with all "remove this" comments made by Michael
As do I -- I just made it very large initially to accommodate the
everyone, and then cut down everything undesirable. I expected when I
that it would be at most two thirds of its original size when (if) it's
Flame? It doesn't look very inflammatory to me...
I think that most of the operations that generate vectors
are useless, especially when the performance is the same as in making
first and then turning it into a vector.
There are two if these -- VECTOR-UNFOLD and VECTOR-UNFOLD-RIGHT --
were some more that somehow escaped my notice and I-search's notice in
when I searched for any usage of LIST->VECTOR and VECTOR->LIST in the
implementation, in places other than where they're defined.
The reason for the existence of vectors is constant-time access by
smaller memory footprint; everything else is better done with lists.
one humongous SRFI for lists pretty much solves the problem; there is
to replicate it for every "linear" data structure. What Scheme needs
orthogonality, not less, and this SRFI (together with large part of
string-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
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
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):
I'm OK with this one, but what about VECTOR-COPY? (the non-destructive
If there is to be an appending operation, then I think it should be
VECTOR-CONCATENATE or VECTOR-CONCATENATE* (the latter of which operates
lists (if you can think of a better name, feel free to), and which lets
what you might otherwise do with APPLY and VECTOR-APPEND. I would
the APPLY and VECTOR-APPEND solution because not only would
trivially implemented with VECTOR-CONCATENATE* (and is in the reference
implementation) but it also avoids the restriction of numbers of
If there is to be a VECTOR-REVERSE!, I think there should also be a
I agree with these, but I'd like to possibly also see
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)
Are these really necessary? I only included them in the SRFI because
in both SRFIs 1 and 13, though I am vaguely against them only for the
that it's hard to implement them more efficiently than with UNFOLD (the
version) and LIST->VECTOR. They're also against the idea of vectors,
because they produce vectors of a size that isn't known when they're
vector-fill! ;extended version
'Extended' meaning the one that takes START and END arguments? If so,
with that, too.
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)
Are there really that many situations in which you would want insert
operations of that sort?
Left/right and circular shifts are also useful.
This sounds useful enough to me.
What do you think about vector operations taking any number of vectors
and END arguments, by the way?