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

Re: SRFI-43: some minor comments

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 Monday, April 7, 2003, at 04:47 AM, Sven Hartrumpf wrote:


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 :-)

"so forth If": add a period


"(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

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.

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?