Per Bothner writes:

> Jussi Piitulainen wrote:
>
>> Testing: would we be in trouble if vectors were arrays and we
>> wanted to generalise vectors another way, to make them able to
>> shrink and grow? It seems to me that those could be disjoint from
>> vectors. No problem for arrays there.
>
> CommonLisp has "adjustable" as an optional property on some arrays.
> An adjustable arrays can change its size with a call to
> adjust-array.

Ok, I don't want to go there at this time. It's just better to know if
the current design would prevent doing that at another time.

[...]
> Shared arrays share the same data vector, but have different shapes
> and transformation maps.

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

> [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.

I'd like to leave adjusting out of this srfi. However:

> 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. But I'd like
to keep arbitrary lower bounds, even if they most often are zeroes.

> Of course an implementation does have the option of using a simple
> array interally for a shape, and having array-shape wrap it in a
> general array, but that means that array-shape would have to do
> object allocation.

That might be acceptable if there were also faster accessors to get at
the bounds. Even in the current implementation, array-rank fetches its
value from the shape.
--
Jussi