David Rush writes:

> I have just scanned through the SRFI document and a fair bit of the
> discussion. Just two quick thoughts.
>
> 1) (array-set! a dim0 dim1 ... dimn val) is a *really* bad specification
>    for this API. Yes, I know it's compatible with vector-set!, but
>    it's still not right. This form is deeply inefficient, requiring
>    list packaging of the dimensions (because of the variable length

Any implementation of a variable number of arguments requires such
packaging. Yours do, below.

>    argument list) *and* the value to be placed in the array is bundled
>    into the same data structure as the indicies.

I suppose the first index could be left out. Then it's the same number
of items in the bag as in number 1 below. Implementations need not
copy the list again, to take the value out from the end. The reference
implementation does not.

In the worst case, if a user really is in a hurry and insists on using
array-set! and building its argument lists dynamically and then using
apply, they can stash the values to the end with set-car! to avoid any
allocation.

>    either of the following is far better:
>         1 (array-set! a val dim0 dim1 ... dimn)
>         2 (array-set! a (array-index dim0 dim1 ... dimn) val)

Both of these use variable length argument lists. The second would
also create some package; to be as efficient as possible, the package
should be the list that the variary mechanism of Scheme builds - just
what array-set! does now but does not expose to the user. And you make
the user call an extra procedure every time they want to pass a couple
of indices to array-set!.

>    I like 2 because of symmetry with the array-shap concept. Also it
>    has the nice possibility of allowing assignments to larger units of
>    the underlying array than just single elements.

I'm rather hoping that array-set! would not be the most common tool in
practice. The latter case here seems more like an array thing already:
treating an arrangement of values as a unit.

> 2) The SRFI should be a completely abstract proposition. There are so
>    many different array implementations that might be desirable in a
[...]
>    for production (I am specifically thinking of numerical & graph
>    applications here where sparse arrays/matrices can be very common).

Hm. Could the sharing mechanism be useful with sparse arrays? Perhaps
it could. I haven't thought of that at all.

>    This means that any vector/array equivalence is a *bad thing* IMO.
>    Preserve disjointness!
--
Jussi