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.
Jussi Piitulainen wrote:
Testing: would we be in trouble if vectors were arrays and we wanted to generalise vectors another way, to make them able to shrink and grow? It seems to me that those could be disjoint from vectors. No problem for arrays there.
CommonLisp has "adjustable" as an optional property on some arrays. An adjustable arrays can change its size with a call to adjust-array. The implementation is straight-forward: You have simple, zero-based, one-dimensional, non-sharable, non-adjustable r5rs vectors, for which you can re-use your existing r5rs implementation. A general array has two parts: A reference to a simple r5rs-style vector, which contains the data, plus a shape, plus a transformation map. (The transformation map is a simple "stride" vector plus a constant displacement.) Shared arrays share the same data vector, but have different shapes and transformation maps. Adjusting an array is just a simple matter re-allocating the data vector and changing the shape, re-setting the transformation map to "unity", and initializing the new data array from the old data 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; this would more-or-less subsume the effect of CL's fill-pointer. However, we need to carefully specify when an implementation can or must re-use the existing data vector, in clarify the sharing semantics when an array is adjusted. Perhaps this needs different primitives: (adjust-array-share array new-shape) -- re-uses existing data vector if big enough, in which case the the values of the data vector are unchanged. (adjust-array array new-shape [initial-value]) -- always allocates a new data array of the size specified by new-shape 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. --Per Bothner