On 8 Apr 2003, Taylor Campbell <xxxxxx@evdev.ath.cx> wrote:
> On Monday, April 7, 2003, at 04:47 AM, Sven Hartrumpf wrote:
> > "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?

The use of bold and italics to mark up unchanged and changed procedures
of R5RS, respectively.

> > "4. Procedures"
...
> > "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?

It does not matter as long as you make the advantages clearer, e.g.
"However, there are two major differences between avectors and alists:
The advantage of avectors is that they occupy only length*2 ...
while alists occupy ...
The advantage of alists is that the number of associations can be more
efficiently changed."

> > avector-change[!]: why are the parameter key and value separated by
> > avector?
>
> I dunno.  What order do you think they should be in?

The rough principle is often someting like this:
[function-parameter-for-higher-order-functions] the-datastructure-itself parameters-needed-for-the-function
This would give in this case: avector key value

> > 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.

If you adopt the above principle, it will be:

update-fun avector key   OR
avector key update-fun (if you regard update-fun as a normal parameter.)

Greetings
Sven