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: > Another question. Vector elements are currently guaranteed to belong > to only one vector. That property would be lost. Perhaps that is not > so important? I don't think that this is a problem -- if you pass a vector to SHARE-ARRAY, you must allow for mutation of the shared array to affect the original vector. I do not think this is very different from the usual Scheme case, where a procedure may stash a reference to a vector somewhere, and this reference later used to mutate the array. In fact, since SHARE-ARRAY can be implemented in Scheme, this is exactly the case. > Can we leave strings out of this? Sure, strings are not interesting arrays unless specialized arrays are introduced, which are certainly beyond the scope of the srfi at hand. > 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. Destructively shrinking a vector used as the base for a shared array would be a problem, since elements that might be referenced through the shared array could go away. There may be reasonable ways to finesse this -- for example the shrinking function could be defined to return a smaller vector, *possibly* destructively shrinking its argument. If vectors are provided with a dirty bit to indicate that they have been passed to SHARE-ARRAY, then they would not be shrinked, but rather copied to a smaller vector