Re: mutable-array setter vs SRFI-17 Jamison Hope 29 Sep 2015 14:04 UTC

On Sep 29, 2015, at 2:06 AM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote:

> On 09/28/2015 07:03 PM, Jamison Hope wrote:
>> On Sep 28, 2015, at 4:44 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>>>
>>> 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.
>>
>> I agree with Per about the argument order, it matches the argument order
>> for set-car!, set-cdr!, string-set!, vector-set!, and the various other
>> setters in (at least) SRFIs 4, 13, 25, 66, 69, 74, and 101 and RnRS (for
>> all n, AFAICT).
>>
>> It also matches the order in which arguments appear for array-setting
>> expressions in other languages:
>>
>> (setf (aref array x y z) newvalue) ;; Common Lisp
>
> I don't see this as an example of your argument.  My understanding is
> that setf is a macro that examines the "form" that is the first of its
> arguments and generates code for a specific setter for each "getter" form

It absolutely is an example.  The details of how SETF works are
incidental.  Fundamentally, if you take away the syntax and read the
values from left to right you get:

array x y z newvalue

>> array[x][y][z] = newvalue;         /* C, C++, Java, ... */

array x y z newvalue

>> Array(x,y,z) = newvalue;           # Matlab

Array x y z newvalue

>> ARRAY[$x]=$newvalue;               # Bash

ARRAY x newvalue

>> $array[$x] = $newvalue;            # Perl

array x newvalue

In every case, first you specify the container, then the cell within the
container, then the new value.  That's the order in which you type the
symbols/values, and so (at least for me) that's the order that users
will be accustomed to think in -- object, location, value.

>> On the other hand, SRFI-47 agrees with you and the world didn't explode.
>
> :-)  I like arguments like this.

Just keep in mind that it makes your API an outlier, which may hinder
adoption.  It may also be error prone, as users who forget about this
quirk may accidentally assign the value x to location (y,z,newvalue)
when they intend to assign newvalue to (x,y,z).  If newvalue is a
fixnum in the appropriate range, it may be a while before the bug is
discovered.

--
Jamison Hope
xxxxxx@alum.mit.edu