Re: SRFI-43: some minor comments Taylor Campbell 08 Apr 2003 11:27 UTC
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: email@example.com > 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?