This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 are here. Eventually, the entire history will be moved there, including any new messages.
Jussi Piitulainen wrote:
Just like srfi-25. If I understand correctly, CL transformation maps are much more restricted.
Yes, they only support a simple displacement, enough to implement sub-sequences (a la shared substring).
[Adjusting an array] If the existing data array is large enough for the new size, we should allow an implementation to re-use the existing data array, for efficiency;That might not be easy. The data under srfi-25 may be in quite different order in the array and in its backing vector.
Yes. It mainly is useful when adjusting (increasing or reducing) the "major" dimension - and msotly only for one-dimensions arrays.
Note an implication of this representation is that you don't want to use a general array for a shape. Instead' you'd want a shape to be a simple (but read-only) vector. So I strongly suggest that the specification be changed to make shape be a *one*-dimensional array - or better yet make it an unspecified opaque type. (In that case for Kawa I would use a simple Java primitive int array.)We could easily make shapes their own type, with accessors (shape-begin shp k) (shape-end shp k) for 0 <= k < (shape-length shp), say, or replace (array-shape arr) with (array-begin arr k) (array-end arr k) for 0 <= k < (array-rank arr), so shapes could still be arrays but a shape of an array would not be accessible, if that would really be useful in practice.
It might be useful to have both, where array-begin is a convenience function (and possible optimization) of shape+shape-begin.
But I'd like to keep arbitrary lower bounds, even if they most often are zeroes.
No objections. --Per Bothner