Email list hosting service & mailing list manager

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