superfluous functions?
Jamison Hope
(29 Sep 2015 16:57 UTC)
|
Re: superfluous functions?
Bradley Lucier
(29 Sep 2015 17:08 UTC)
|
Re: superfluous functions?
Jamison Hope
(29 Sep 2015 17:48 UTC)
|
Re: superfluous functions?
Bradley Lucier
(07 Oct 2015 01:15 UTC)
|
Re: superfluous functions? Jamison Hope (11 Oct 2015 14:45 UTC)
|
Re: superfluous functions?
Bradley Lucier
(16 Oct 2015 17:44 UTC)
|
Re: superfluous functions? Jamison Hope 11 Oct 2015 14:45 UTC
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. > 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]. 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). 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))) My 2¢, I'd like not to be the only one opining here though.. -- Jamison Hope xxxxxx@alum.mit.edu