[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

multiple vector arguments versus start+end



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