Tooken me time, but here is.

This concerns array-ref and array-set! and the way to specify the
index. My original offer was to specify each index as a separate
argument. That has not changed. An alternative is added.

There were requests to package the index sequence in an object, on two
different grounds. First, it would be significantly more efficient to
reuse an index object than allocate new argument lists when iterating
over an array. (How significantly? We don't know.) Second, one might
want to express the index as an array. An example provided used rows
of a two-dimensional array to index another array.

I have now tested the expression of array algorithms by implementing a
few iteration procedures. The use of an index object does make writing
such things rather more straightforward than argument lists of unknown
length. Decision: index objects seem worth the trouble.

What I have now is alternative interfaces to each access procedure.
These are as follows, where `index' can be either a vector or a
zero-based one-dimensional array with elements containing `k ...'.

(array-ref arr k ...)
(array-ref arr index)

(array-set! arr k ... o)
(array-set! arr index o)

I have implemented and tested this interface three different ways.

One portable way to get rid of the dreaded runtime allocation of
variable length arguments lists would be to split the procedures in
two (or three): use different names for the alternative interfaces.

Another way, for highest efficiency, would be to use a restricted
implementation with only (array-ref arr vec), (array-set! arr vec o)
provided.

A third way might be the use of case-lambda to make the important
branches more efficient. (With lambda, even the first index argument
is optional, because of zero-dimensional arrays.)

So there is a question, do we keep the above interface, or instead
something like the following:

(array-ref arr k ...)
(array-ref/index arr index)

(array-set! arr k ... o)
(array-set/index! arr index o)

or maybe hide the alternative interface from the specification? (It
would still be useful for library writers, or library writers can use
a lower level implementation that avoids variarity already.)

Either way, I consider it a virtue that this proposal does not
introduce a new object type for indexes. The only new type is still
the array.

Today, DrScheme launches with a progress bar that shows Adam and God
reaching for each other. Merry Christmas,
--
Jussi