Many good points.

On 10/11/2015 10:45 AM, Jamison Hope wrote:
>
> On Oct 6, 2015, at 9:15 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>
>> How's this for a new API and description for array-curry (still in
>> progress):
>>
>> Procedure: array-curry array outer-dimension [ subarray-type 'immutable ]
>>
>> If array is an array whose domain is an interval [l0, u0) x ... x [ld-1,
>> ud-1) and outer-dimension is an exact integer strictly between 0 and d,
>> then array-curry returns an (immutable) array with domain [l0, u0) x
>> ...x [louter-dimension-1, uouter-dimension-1), each of whose entries is
>> in itself an array with domain [louter-dimension, uouter-dimension) x
>> ... x [ld-1, ud-1).
>
> Better, but it could still be more clear about how the elements of the
> return value relate to the elements of the array argument.  The way
> it's worded here, the function could just be using the array argument as
> a prototype to figure out the correct domain and type.

Good catch.  I'll add something.

>
>> The type of the subarrays is determined by the optional argument
>> subarray-type in combination with the type of the input array.
>>
>> If subarray-type is 'mutable, and the input array is mutable (which
>> includes specialized arrays), then each subarray is mutable.
>>
>> If subarray-type is 'specialized and the input array is specialized,
>> then each subarray is specialized.
>
> Does subarray-type always have to be either 'immutable or the same as
> the type of the input array?  In that case, the last argument is really
> just a binary choice: [immutable] vs [same as input].

I'm going to change it so that the type of all the subarrays is the same
type as the input array, no optional argument

>
> But I think what I really want to know here is whether (or when)
> array-curry is making a copy of the data, or just providing a new view
> into the original.  If it isn't a copy, then the distinction between
> 'mutable and 'specialized seems irrelevant -- the result's setters just
> wrap a call to the original's setter either way.  And if the original
> doesn't have a setter because it's immutable, array-curry should be able
> to figure that out on its own without me passing an argument.
>
>
> I might just prefer array-curry to always return an array-of-arrays with
> the same mutability as its argument and forgo subarray-type completely:
>
> (array-curry ARR N)
>
> returns an array of immutable arrays if ARR is immutable, otherwise
> returns an array of arrays whose setters call through to ARR's setter.
>
>
> The implementation would probably be simplified if the array and
> mutable-array functions were merged, so that array takes an optional
> setter (or #f).

I haven't thought this one through, but I'll probably do it.

>
>
> If I want to produce an immutable view into an array, maybe that should
> be a distinct operation, something like
>
> (define (immutable-array ARR)
>    (array (array-domain ARR) (array-getter ARR)))

Thanks for your comments.

Brad