I see that SRFI 4 does not mention resizing of vectors. I'm using f64vectors (for which I need fast access), and I'd like to be able to resize them quickly (similar to what realloc does in C), and not necessarily copy the whole vector.
Since I didn't find any references to a "resize-f64vector" procedure, I'd like to know why it doesn't exist (and if making a new vector and copying over is my only option).
Gambit-C Scheme can shrink vectors, but if you want a general solution you are out of luck. You can use vectors of a bigger size than needed to avoid frequent re-allocation and copying, like doubling the vector everytime you need more space and keeping a count of the number of slots really used.
Couple reasons.
By having a homogeneous vector type within the language, the compiler can make some solid assumptions about performance. Ideally, in some heavily optimized scenarios, the reference to the vector can be little more than a point to a block of memory. Not saying any Scheme implementations actually do this, but they can do this.
Given that, almost every time a vector is resized, it's most like copied to a new memory location that can hold the new vector. Just the raw truth of it with the way memory is laid out.
So, given that, you can see how if all I have is a pointer to memory, if that buffer is changed and moved, then my pointer is no longer valid. It points to the old memory.
But if I can assume that my memory size will never change, then it's a safe bet, against as an optimization by the compiler, that the memory for my vector will never change, and that I can represent and reference that vector as simply a pointer to memory.
And that's the primary goal of the homogeneous vectors, to give potentially faster access to specialized blocks of memory.
Since resizing a vector almost inevitably involves a copy, you may as well make that copy explicit, giving the compiler full visibility to the changes in the reference to the vector.