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.

The implementation is straight-forward:  You have simple, zero-based,
one-dimensional, non-sharable, non-adjustable r5rs vectors, for which
you can re-use your existing r5rs implementation.

A general array has two parts:  A reference to a simple r5rs-style vector,
which contains the data, plus a shape, plus a transformation map.
(The transformation map is a simple "stride" vector plus a constant
displacement.)  Shared arrays share the same data vector, but have
different shapes and transformation maps.

Adjusting an array is just a simple matter re-allocating the data vector
and changing the shape, re-setting the transformation map to "unity",
and initializing the new data array from the old data 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;
this would more-or-less subsume the effect of CL's fill-pointer.
However, we need to carefully specify when an implementation
can or must re-use the existing data vector, in clarify the sharing
semantics when an array is adjusted.  Perhaps this needs different
primitives:

(adjust-array-share array new-shape)
  -- re-uses existing data vector if big enough, in which case the the
  values of the data vector are unchanged.

(adjust-array array new-shape [initial-value])
  -- always allocates a new data array of the size specified by new-shape

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

    --Per Bothner