[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Dec 16, 2003, at 3:06 AM, Michael Sperber wrote:
Taylor> Too bad you hadn't done this extensive vector hacking back
Taylor> concept of a draft period still occurred to some of us...well,
Taylor> have opinions on the past few issues that I've brought up,
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
Taylor> the insertion & deletion routines,
Zap 'em, I say. Marginal value, conceptual & space overhead in the
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?)