In the example I gave previously, this can result in much greater
temporary memory use, up to 192 times in Gambit for bit arrays (which
Gambit reports as 384 times because it has a stop-and-copy garbage
collector, so it reports both space allocated in the old heap and space
that it might need in the new heap if that structure survives GC).
Can you explain the space cost? In procedures like `vector-map` at most one copy is needed when `vector-map` returns so the space cost can be at most twice. The actual cost can be much lower, depending on the quality of the GC.
I assume that's the size of a pair in bits. It's a horrendous cost for a gain that will not matter in the majority of cases, so I think it makes sense to provide either option.
After this preliminary work, I'm inclined to have a parameter that tells
the code whether to use call/cc-safe algorithms or not to use
call/cc-safe algorithms. Perhaps named
use-call/cc-safe-array-algorithms
Which procedures will be affected by this parameter?
Don't use a parameter. Export the procedures under two different names (or under the same name but in two different sub-libraries). A parameter wouldn't make much sense here.
What will the default value be? I would say that people will expect it to be #f, especially as there will be a time cost as well as a space cost.
I would say that people expect the procedures to work well and compose well with the core Scheme facilities, which include call/cc.
I am going to write PFNs for the following SRFIs warning that the use of multiple returns produces unspecified results: 133 (general vectors), 160 (homogeneous non-bit vector), 178 (bit vectors), 196 (ranges), and 214 (flexvectors). If anyone wants to write space-eating SRFIs that are call/cc-safe, by all means do so.
On the contrary, to be viable for inclusion in a future Scheme standard, I think that these APIs must honor Scheme's primitives like call/cc. If they don't, call/cc (when used non-trivially) and friends will become merely procedures for toying around but hardly usable in more complicated code bases.
If we ignore this, the R7RS-large project would just create another Common Lisp, now in form of a Lisp-1 instead of a Lisp-2.