On 11/30/19 7:58 PM, John Cowan wrote:

> I should have been clearer.  SRFI 122 guarantees that the user can create arrays whose elements are limited to one of the SRFI 160 vector types (that is, SRFI 4 + complex64 + complex128).

As does SRFI 164 (assuming the implementation or specification supports SRFI 4/160).

> However, it does *not* guarantee that the elements are stored compactly: they might be stored in an ordinary Scheme vector.

That would be very strange.

> On the gripping hand, it guarantees that arbitrary user-defined storage objects with the correct interface can store an array of the first kind (for example, a hashtable paired with a default value, which would serve as a compact representation of a sparse array).  SRFI 164 provides none of these guarantees to the user: what types of storage objects are available is determined by the implementation.

SRFI 164 has the concept of a "gvector" - and I tend to think of a SRFI 122 "storage class"
as basically a specific sub-class of gvector.

I didn't try to specify a way to create new gvector types because the I think
natural way to do it is to define a new "interface type" that "extends" gvector.
That is the natural way to in most object-oriented platforms (including Java and Kawa),
but some people (including seemingly you) are leery of inheritance, at least in
terms of how Scheme should be designed.

However, there is nothing preventing adding support for SRFI 122 storage classes
to SRFI 164.  For example one could add the procedure

     (make-specialized-array SHAPE STORAGE-CLASS)

to SRFI 164 fairly easily, I'm pretty sure.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/