This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.
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