[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 are here. Eventually, the entire history will be moved there, including any new messages.



On 8 Apr 2003, Taylor Campbell <campbell@xxxxxxxxxxxx> 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