Radey Shouman writes:
> Per Bothner writes:
[...]
>> simple Java primitive int array.) 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.

It could keep one shape representation for external access and another
version for internal purposes. Or one might be able to arrange things
so that the efficient version is the backing vector for the externally
accessible shape array.

> I would like to strongly second the suggestion to make the array
> shape an unspecified opaque type. A two-dimensional array may well
> be optimal in the reference implementation, but it will likely be a
> burden for more primitively implemented arrays.

I'll think of it. But aren't arrays opaque in the relevant sense? The
current design was influenced more by the internal consistency of the
package, and the expressiveness of it - all the tools that we have not
yet even thought about would be available for shape manipulation -
than efficiency.

>                                                 Also, I find the
> idea that an array shape object should become immutable only after
> passing it to one of the array functions as a shape to be a little
> bit weird.

Ocuh. That's not the idea. In the current implementation, (shape 0 3)
is already immutable, and if (array (shape 0 1 0 2) 0 3) is used as a
shape, it is just a bad thing to mutate that array. I was thinking of
making a copy of it if it isn't flagged as shape already.
--
Jussi