Re: mutable-array setter vs SRFI-17 Bradley Lucier 28 Sep 2015 20:44 UTC

On 09/27/2015 12:33 AM, Per Bothner wrote:
> In this letter I'll rename the specification of mutable-array to avoid
> confusion, to:
>    (mutable-array domain get-proc set-proc)
> The "standard" Scheme argument-order for a "set-proc" is to have the new
> value *last*.
> E.g. (vector-set! vec index new-value).  That is why SRFI-17 defines:
>    (set! (proc arg ...) value)
> as
>    ((setter proc) arg ... value)
> The setter procedure passed to mutable-array has the order:
>    (setter value i1 ... in)
> I think it should be:
>    (setter i1 ... in value)
> That would allow:
>    set-proc == (setter get-proc)
> Of course the downside of that is that you can't use a "rest" argument to
> writer the setter:
>    (lambda (value . indexes) ...)
> This issue is discussed in SRFI-17.

Thank you for your comments; I have thought about similar issues.

Newly-developed procedures have differed from previous naming
conventions.  Thus we have




I think the order of arguments to vector-set! was an error that doesn't
become clear until you use a multi-index instead of a a simple index as

> We can "have the best of both" by changing the get-proc to
> take a single vector-valued argument:
>    (get-proc (vector i1 ... in))
>    (set-proc (vector i1 ... in) value)
> One really wants to be using a vector of indexes rather than a list
> of indexes.  And preferably a uniform fixnum vector.
> Note that SRFI-25 has:
>    (array-set! array k ... value)
> SRFI-25 also allows array indexes:
>    (array-ref array indexes)
>    (array-set! array indexes value)
> where indexes is a vector or a rank-1 array.
> These variants would be the lower-level one, that would call the
> mutable-array get-proc and set-proc.  The variable-length array-ref
> and array-set! would be convenience methods that call the vector-based
> ones.

I'm sorry, but I don't agree.  The schemers who introduced
values/call-with-values into scheme didn't reify the output of the
values procedure (presumably for two reasons, to have multiple output
values parallel multiple arguments, and for optimization oportunities),
and I don't think we should use a reified multi-index (whether a list or
a vector) as an argument.

I can see how one might use a lower-level array implementation as a base
for implementing this SRFI.