multiple vector arguments versus start+end
Taylor Campbell 30 Nov 2003 18:48 UTC
This has been mentioned once before by me. I didn't get any response.
I'm not entirely sure if I want to continue SRFI 43, given that SRFI
47 ('Array') now exists, and there is a possibility for a much more
general array library. However, if this SRFI is to continue, then I
should like to resolve this issue. There are several solutions:
1. Use start+end arguments where multiple vector arguments don't make
sense and start+end ones do; use multiple vector arguments in
arbitrary places where they do make sense. (This is what is used
currently.)
Problems: Where multiple vector arguments are used is fairly
arbitrary and I don't like it. There are many places where
_either_ one would work, and using VECTOR-COPY/RESIZE to extract
different segments of vectors to apply the operations that take
multiple vector arguments to is silly and miserably inefficient.
2. Use start+end arguments everywhere. (This is what SRFI 13 uses.)
Problems: It's often useful to be able to use multiple vector
arguments to certain operations, and it would be consistent with
other versions of those operations: MAP, FOR-EACH, et cetera.
3. Create a new vector type with bound components for fast resizing
and component selection.
Problems: This _drastically_ changes the SRFI and given how
overdue the SRFI is already (five months! Yeek!), I don't think
right now is a good time to suddenly start extending the
representation of vectors drastically, especially when new, more
general array libraries are unfolding.
None of those solutions is particularly appealing to me. Opinions?
(I also toyed with the idea of an intervals SRFI, to be used, for
example, as:
(vector-copy VEC (make-interval 'x 3 'i 5))
-- copy VEC using the interval 3 (exclusive) to 5 (inclusive), for
maximal ease of finding intervals and without any confusion over
inclusive versus exclusive indices. It could be used alongside option
3. But I only toyed with it; I don't plan to write up a draft of it
unless popular demand demands it.)