Email list hosting service & mailing list manager

multiple vector arguments versus start+end Taylor Campbell (30 Nov 2003 18:47 UTC)
Re: multiple vector arguments versus start+end Taylor Campbell (20 Dec 2003 18:43 UTC)

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.)