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 <per@xxxxxxxxxxx> writes: > > > 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.) 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. > > 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. 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. Thirded. Making an array shap an array seems to be confusing specification with implementation. I think that you're really defining two types of objects in this SRFI, arrays *and* shapes. Brad