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
set-car!
but
vector-set!
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
argument.
>
> 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.
Brad