This page is part of the web mail archives of SRFI 43 from before July 7th, 2015. The new archives for SRFI 43 contain all messages, not just those from before July 7th, 2015.
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 theTaylor> 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?)