Jussi Piitulainen wrote:

>Just like srfi-25. If I understand correctly, CL transformation maps
>are much more restricted.
>

Yes, they only support a simple displacement, enough to implement
sub-sequences (a la shared substring).

>>[Adjusting an array] If the existing data array is large enough for
>>the new size, we should allow an implementation to re-use the
>>existing data array, for efficiency;
>>
>That might not be easy. The data under srfi-25 may be in quite
>different order in the array and in its backing vector.
>
Yes.  It mainly is useful when adjusting (increasing or reducing)
the "major" dimension - and msotly only for one-dimensions arrays.

>>Note an implication of this representation is that you don't want to
>>use a general array for a shape. Instead' you'd want a shape to be a
>>simple (but read-only) vector. So I strongly suggest that the
>>specification be changed to make shape be a *one*-dimensional array
>>- or better yet make it an unspecified opaque type. (In that case
>>for Kawa I would use a simple Java primitive int array.)
>>
>
>We could easily make shapes their own type, with accessors
>
>   (shape-begin shp k)
>   (shape-end shp k)    for 0 <= k < (shape-length shp),
>
>say, or replace (array-shape arr) with
>
>   (array-begin arr k)
>   (array-end arr k)    for 0 <= k < (array-rank arr),
>
>so shapes could still be arrays but a shape of an array would not be
>accessible, if that would really be useful in practice.
>
It might be useful to have both, where array-begin is a convenience function
(and possible optimization) of shape+shape-begin.

>But I'd like
>to keep arbitrary lower bounds, even if they most often are zeroes.
>
No objections.

    --Per Bothner