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: xxxxxx@fernuni-hagen.de
> 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?