mutable-array setter vs SRFI-17
Per Bothner
(27 Sep 2015 04:33 UTC)
|
Re: mutable-array setter vs SRFI-17
Bradley Lucier
(28 Sep 2015 20:45 UTC)
|
Re: mutable-array setter vs SRFI-17
Jamison Hope
(28 Sep 2015 23:03 UTC)
|
Re: mutable-array setter vs SRFI-17
Bradley Lucier
(29 Sep 2015 06:06 UTC)
|
Re: mutable-array setter vs SRFI-17 Jamison Hope (29 Sep 2015 14:04 UTC)
|
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