Yes, thanks. I've been looking closely at 164 to see if it can be implemented on top of 231, now that the 231 dharma line includes zero-dimensional and empty (degenerate) arrays. 231 doesn't directly support arbitrary affine transforms, but the method described in the implementation note of `share-array` will of course work correctly.
There will be some slightly unexpected results: Scheme vectors and SRFI 160 vectors (SRFI 4 + c64vector + c128vector) will be SRFI 164 arrays by ad hoc polymorphism, but a procedure that happens to return a 1-dimensional array (other than array->vector) will not return a Scheme or SRFI 160 vector. On Sat, Sep 2, 2023 at 11:35 AM Per Bothner <[email protected]> wrote: > > > On 9/1/23 23:08, John Cowan wrote: > > In CL the function row-major-aref accepts an array and a single index > *n* and returns the *n*th element of the array in row-major order. There > is a corresponding function (setf row-major-aref) serving as the > corresponding mutator. This is equivalent to: > > > > (define (row-major-aref array n) > > (vector-ref (array->vector array) n)) > > > > but does not reify the results of `array->vector`. Is there some way to > do this with SRFI 231? > > In srfi-164 array->vector returns a view, not a copy. > So your define works, and the same approach works for setting. > > It is unfortunate that array->vector is incompatible between srfi-231 and > srfi-164. > -- > --Per Bothner > [email protected] http://per.bothner.com/ >
