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.
On Monday, Oct 27, 2003, at 22:46 US/Eastern, Alex Shinn wrote:
A couple comments. For vector-copy! Guile provides vector-move-left! and vector-move-right!, so that you can safely copy a vector onto itself (useful for implementing -insert/-delete). You don't really need the -left!/-right! distinction, so long as you check the TSTART vs. FSTART (if TSTART is smaller you copy left->right, if FSTART is smaller you copy right->left). So the API can remain the same but it's probably worth requiring in the SRFI that TARGET and VEC are allowed to be the same vector.
This sounds like a good idea (in fact, it's what SRFI 13 does with its STRING-COPY!). I shall put this in the next revision of the document and implementation.
For the CMP of vector-binary-search, is there a consensus on returning symbols?
Nope. That was pretty arbitrary on my part.
You could pass a < predicate which is consistent with the sortSRFI and allows use of built-ins like string-ci<?, or use a comparator with a positive/negative/zero as in C which allows the use of the built-in - procedure.
Yes, I realized a while ago that it would be better to use positive/ zero/negative results for the comparison procedure. I shall change this as well.
Of course, you didn't comment on the insertion and deletion stuff like I asked you to...that stuff is about the only reason I haven't made the final word to finalize the SRFI. And it occurs to me that no one mentioned anything about the /INDEX variants of VECTOR-MAP[!] and VECTOR-FOR-EACH; the document doesn't specify where the index argument is. I'd prefer it to be the first argument. Would anyone mind if I made this change, even though it's incompatible with the current reference implementation? (which, of course, I shall fix as well)