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.
Radey Shouman writes: > Per Bothner writes: [...] >> simple Java primitive int array.) Of course an implementation does >> have the option of using a simple array interally for a shape, and >> having array-shape wrap it in a general array, but that means that >> array-shape would have to do object allocation. It could keep one shape representation for external access and another version for internal purposes. Or one might be able to arrange things so that the efficient version is the backing vector for the externally accessible shape array. > I would like to strongly second the suggestion to make the array > shape an unspecified opaque type. A two-dimensional array may well > be optimal in the reference implementation, but it will likely be a > burden for more primitively implemented arrays. I'll think of it. But aren't arrays opaque in the relevant sense? The current design was influenced more by the internal consistency of the package, and the expressiveness of it - all the tools that we have not yet even thought about would be available for shape manipulation - than efficiency. > Also, I find the > idea that an array shape object should become immutable only after > passing it to one of the array functions as a shape to be a little > bit weird. Ocuh. That's not the idea. In the current implementation, (shape 0 3) is already immutable, and if (array (shape 0 1 0 2) 0 3) is used as a shape, it is just a bad thing to mutate that array. I was thinking of making a copy of it if it isn't flagged as shape already. -- Jussi