Email list hosting service & mailing list manager

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)

Re: relationship to SRFI-25 Jamison Hope 28 Sep 2015 23:20 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