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.
Sergei Egorov wrote:
<Flame> 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.
- which of course is never.
The reason for the existence of vectors is constant-time access by index and smaller memory footprint; everything else is better done with lists.
I'd say: (almost) everything is better done with vectors, if you care about performance at all.
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 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. 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.
This I very much agree with - however it is very different from the historical "Scheme way of doing things." (Kawa does have vectors, lists, strings, and uniform-vectors all special cases of sequences.)
I suggest to drop everything that is not related to the main purpose of vector's existance: constant-time indexed access.
Linear-time operations, such as iterating over all the elements of a sequence, are also typically much faster using vectors, thanks to better cache utilization. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/