[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 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?)