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?