On Dec 16, 2003, at 3:06 AM, Michael Sperber wrote:

> Taylor> Too bad you hadn't done this extensive vector hacking back
> when the
> Taylor> concept of a draft period still occurred to some of us...well,
> do you
> Taylor> have opinions on the past few issues that I've brought up,
> namely the
> Taylor> things regarding VECTOR-COPY!,
>
> I agree with your conclusions.  (Or is there anything unresolved I
> missed?  If so, let me know.)

Er, hmm.  I don't remember my conclusions...in fact, thinking about it
again, I don't remember the _issue_.  I guess that one was resolved
pretty quick!

> Taylor> the insertion & deletion routines,
>
> Zap 'em, I say.  Marginal value, conceptual & space overhead in the
> SRFI document.

Well, I put them in in the first place by specific request from Sergei
Egorov.  If no one has found them useful (I haven't, anyways; perhaps
he has, in which case he should pipe up), I shall remove them.

> Taylor> and the issue regarding start+end versus N vector arguments?
>
> Hm, I actually think the way things are isn't half bad.  This really
> is the kind of thing where only experience helps, so I wouldn't worry
> about it too much now.  I do suspect, though, that the procedures
> under "Searchers" would be better off with start+end args rather than
> N vectors, though.

The thing about this issue is that the _right_ thing to do is have a
real vector slice API.  But that's too radical for an already six-
months-overdue SRFI.  For _all_ operations vector slices would make
sense, but only for _some_ would multiple vector arguments -- but then
again, it's _really_useful_ for those to accept multiple vectors --.
So I'm really undecided about what to do.  This is about the only
significant pending bit.

(One minor bit that I haven't really gotten anyone else's opinion on,
but I've been planning on anyways: is anyone opposed to switching the
comparator in VECTOR-BINARY-SEARCH to returning negative/zero/positive
integers, rather than the symbols LT/EQ/GT?)