tAm Di., 13. Okt. 2020 um 04:54 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Mon, Oct 12, 2020 at 10:39 AM Erik Dominikus <xxxxxx@gmail.com> wrote:
>
>>
>> It is possible to make vectors resizable while maintaining backward
>> compatibility with Scheme, by adding the concept of "capacity" to
>> "vector".
>
> That is, it is possible for implementers to do so, but it is not possible for users to do so in general, because they typically have no control over the implementation of vectors in the Scheme they are using.  (I won't rehash the difficulties with using rename-on-import to make vector-ref, -set, etc, work on flexvectors: suffice it to say that it must be done throughout a program, or libraries not compiled with that feature will blow up when they try to work on a "vector" that isn't in fact a vector.)

This is an argument against anything that cannot be portably
implemented, isn't it?

> However, I think it would suffice to add a note to the SRFI saying that flexvectors and vectors are not necessarily disjoint, which would allow an implementation in this style to correctly implement the SRFI as it stands.

That's a good idea.

>> Each vector can grow or shrink as much as it likes, as long as its
>> size does not exceed its capacity. If it has to grow above its
>> capacity, it signals an error or reallocates its content.
>
>
> Which is it?  It could use `raise-continuable` to signal error which, if continued from, would expand the vector in question, but could also be further propagated.  I don't think this is a very useful feature myself, but I'm not outright opposed to it.  To provide it, a further procedure `vector-capacity` is needed, returning #f if the capacity is unbounded.

If an exception is raised whenever the vector has to reallocate
itself, this will probably detrimental to its performance (as going
through exception handlers may not be the fastest thing in the world)
when all what the programmer wants is that the vector does the
reallocation.

>> - It requires changing the layer below Scheme, although the change
>> should be small if the underlying layer does not assume that vector
>> contents cannot move.
>
>
> It's not so small when you figure the total cost of persuading implementers to do it.  As SRFI 214 stands, implementers don't have to do anything at all, as a portable implementation is practical.

This is an argument often repeated. For the vast majority of the
currently existing R7RS-large SRFIs, implementers don't have to do
anything at all. And yet, they would have to do anyway if they want to
provide a competitive solution. Take SRFI 146 (mappings and hamts) for
example. The Scheme implementation is fully portable but cannot
compete at all with a native implementation in C  unless you have an
extremely well optimizing Scheme compiler. The same may be true for
the data type of SRFI 214.

Marc