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

Re: SRFI-43: some minor comments




On Monday, April 7, 2003, at 04:47 AM, Sven Hartrumpf wrote:

Hello.

Thanks for this SRFI. After reading SRFI-1 one would expect this SRFI as SRFI-2
:-) It's good to see that somebody is filling this gap.

"3. Procedure Index":
The markup you introduce should also be used in section 4.

I don't quite see what you mean...could you be a little more specific?

"4. Procedures"

"end: .. This indicates the index at which traversal of a vector ends."
Maybe this is ambiguous (including or excluding end; maybe "before" is
clearer. (Sorry, I am not a native as you can read here :-)

vector=:
"so forth If": add a period

Whoops.

"(vector=eq?)": delete one of the two

Whoops again.

vector-concatenate: "bork" ?

I couldn't think of a better term at the time. I'll reword it to explain that some Schemes don't let you pass more than some fixed number of arguments, due to
a small stack or something.

vector-map-left etc.: vector-map-in-order (others: ... -in-reverse-order)
 are more in line with SRFI-1?

The VECTOR-MAP-X[!] procedures I intended to let people discuss on the mailing list. I didn't particularly like having MAP, MAP-IN-ORDER ('in order' I find a little ambiguous, too ('right to left' is in a specific order, but it's not the specific order that MAP-IN-ORDER uses), which is why I chose VECTOR-MAP-LEFT), and MAP!, so I changed it around a bit. I do agree that it isn't very congruent with SRFI 1, and I also intend to cut some of the less necessary ones away after
hearing what other people have to say.

vector-any: "applied each" add "to" in between?

Whoops a third time.

"Association Vectors": "they also occupy": why "also"?

Do you think the sentence should be rephrased as

'Avectors are constant size, but they occupy LENGTH*2 cells); alists ...'

since it is something of a limitation that avectors are constant size?

Or should I rephrase it even differently and put the 'limitation' after the
advantage?

avector-change[!]: why are the parameter key and value separated by avector?

I dunno.  What order do you think they should be in?

Suggestion: avector-update[!]: like avector-change but instead of "value" a unary function for updating is supplied, e.g. (lambda (old-value) (+ old-value 1)). These functions are important for the efficient implementation of some algorithms.

Ah, good idea.

Its parameters will be the similar to AVECTOR-CHANGE[!]'s (KEY then AVECTOR then
F), only until someone decides on what the order ought to be.

Greetings
Sven
--
Sven Hartrumpf         e-mail: Sven.Hartrumpf@xxxxxxxxxxxxxxxx
Computer Science VII   phone:  +49 2331 987 4553
University of Hagen    fax:    +49 2331 987  392
58084 Hagen - Germany  http://pi7.fernuni-hagen.de/hartrumpf


PS: Could you send directly to the SRFI 43 mailing list, instead of sending it
directly to me?