relationship to SRFI-25
Per Bothner
(30 Jul 2015 05:30 UTC)
|
Re: relationship to SRFI-25
John Cowan
(30 Jul 2015 20:20 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(31 Jul 2015 21:00 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(26 Sep 2015 18:33 UTC)
|
Re: relationship to SRFI-25
Per Bothner
(27 Sep 2015 05:34 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(28 Sep 2015 21:04 UTC)
|
Re: relationship to SRFI-25
Per Bothner
(28 Sep 2015 21:29 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(28 Sep 2015 21:54 UTC)
|
Re: relationship to SRFI-25
Jamison Hope
(28 Sep 2015 22:22 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(28 Sep 2015 22:38 UTC)
|
Re: relationship to SRFI-25 Jamison Hope (28 Sep 2015 23:20 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(29 Sep 2015 06:03 UTC)
|
Re: relationship to SRFI-25
Jamison Hope
(29 Sep 2015 16:12 UTC)
|
Re: relationship to SRFI-25
Bradley Lucier
(30 Sep 2015 03:42 UTC)
|
On Sep 28, 2015, at 6:38 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote: > On 09/28/2015 06:22 PM, Jamison Hope wrote: >> On Sep 28, 2015, at 5:53 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote: >> >>> (4) when using this array API there is no point in this whole process where a bang occurs textually. >> >> This could be resolved quite easily if the API provided array-set! instead >> of just array-setter. I hesitate to suggest adding more procedures to the >> API, since I think there are already too many, but it would feel much more >> natural if there were array-get and array-set! procedures that called >> array-getter and array-setter under the hood. > > > Here are those procedures: > > (define (array-ref a . args) > (apply (array-getter a) args)) > > (define (array-set! a v . args) > (apply (array-setter a) v args)) > > From my point of view these procedures achieve very little (accessing or setting one value in an array) with either (1) the cost of a lot of error checking, (2) the dangers of no error checking, and (3) the cost of calling apply. > > I could go through and look at the dimension of the domain of a and specialize the calling sequence for small dimensions to avoid using apply. That would add a dozen lines of code. > > But that's exactly the same kind of checking and specialization that is needed for array-map, array-reduce, or any of the other full array operations. That checking and specialization is done *once*, and benefit the operations on *all* the elements of the array. I hope that some of this is understandable from the reference implementation. I don't really understand this part. I'm not suggesting that array-map be implemented on top of array-ref, or that whatever other mutating functions there are be implemented on top of array-set! -- just that as an end user, having to extract and then invoke a closure rather than just calling a setter or getter *function* seems strange. I haven't grokked the reference implementation yet, though, either. > I don't find that these word-by-word operations are helpful for my codes (which I consider to be real codes). OK, I was just looking at your example to Per, which had ((setter b) #t 0) That's the line that needs a bang, since that's where the mutation happens. -- Jamison Hope xxxxxx@alum.mit.edu