Re: various comments Jussi Piitulainen (17 Nov 2001 14:03 UTC)
Re: various comments Radey Shouman (17 Nov 2001 18:27 UTC)
Re: various comments Jussi Piitulainen (18 Nov 2001 14:50 UTC)
Re: various comments Per Bothner (19 Nov 2001 19:52 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 08:14 UTC)
Re: various comments Per Bothner (20 Nov 2001 18:35 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 19:20 UTC)
Re: various comments Per Bothner (20 Nov 2001 19:33 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 20:14 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:31 UTC)
Re: various comments Radey Shouman (19 Nov 2001 23:26 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 08:43 UTC)
Re: various comments Per Bothner (20 Nov 2001 19:20 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 20:02 UTC)
Re: various comments Per Bothner (20 Nov 2001 21:08 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:58 UTC)
Re: various comments Jussi Piitulainen (21 Nov 2001 16:52 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:47 UTC)
Vectors as arrays Re: various comments Jussi Piitulainen (20 Nov 2001 18:03 UTC)
Re: Vectors as arrays Re: various comments Radey Shouman (21 Nov 2001 04:09 UTC)

Re: various comments Radey Shouman 21 Nov 2001 03:47 UTC

Jussi Piitulainen <xxxxxx@ling.helsinki.fi> 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