On 5/6/21 10:29 PM, Alex Shinn wrote:
>>> I was caught by this implementing a new utility,
>>> array-concatenate.  Trying to rely on high-level operations,
>>> a clean way to implement this is to construct the destination
>>> which is the sum of the two input domains along a dimension,
>>> then array-assign! each input to its array-extracted offset
>>> within the destination.  But these elements will not be
>>> adjacent.
>>>
>>> Without being able to use array-assign! and without interval
>>> cursors, the implementation of concatenate is quite difficult.
>> You see how to do it, you just have to translate each argument array to
>> match the domain of the array-extract'ed subarray of the result.
> Ah, right, that's a usable workaround.  But I was curious about the
> motivation of the restriction.  It seems an implicit translation is more
> natural than an implicit reshape.

I think the optional domain argument was added to array-copy before
specialized-array-reshape was available, and before I understood the
conditions under which one could reshape (or not) a general specialized
array.

I now think it would be better to remove the optional domain argument to
array-copy and to use the style

(specialized-array-reshape (array-copy ...) new-domain)

I suppose it would be good to collect together the ideas that have come
up in these discussions in an "Issues" section of the SRFI document for
future consideration.

Brad