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 <jpiitula@xxxxxxxxxxxxxxxx> writes: > I've been thinking of this. I begin, slowly, to see that (1) there > really is essentially no runtime cost for arrays, and (2) that R5RS > vectors need not be redefined at all. So it seems like a win. > > Now, sharing a vector, or an array that shares a vector, can in some > cases produce an array that essentially is that vector. Should we > specify that the result of share-array is never a vector, or is a > vector when it can be, or leave it unspecified? I don't think that we want to specify that an array construction procedure must return a vector in any case -- completely disjoint vectors and arrays should be allowable as an implementation tactic. SHARE-ARRAY should not be different than other array construction procedures: if a vector return value meets the specification, then it should be allowed but not required. This freedom of implementation should not be a burden on array-using programs. Objects produced by array construction procedures may always be indexed using ARRAY-REF, objects produced by standard Scheme vector construction procedures may always be indexed using VECTOR-REF.