[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
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 list
first 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's
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
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 reference
implementation) 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?