On Sunday 24 July 2005 14:55, skaller wrote:
> If you have to initialise the store, it is expensive,

I understand your point now. However, if you want your array to hold 
allocated values, you will always have to initialise the array. Moreover, 
I think the overhead of this initialisation is insignificant compared to 
the GC overhead.

> and if you have to provide a dummy value it is hard
> to use.

Maybe hard is not the appropriate word. I would just say annoying. You can 
always define easily a dummy value when you define a (non-empty) type. One 
may argue that you may need to compute a path in a type dependency
graph, but it is far-fetched: the path is given by the type definition!

> then you can use the first value of the array as
> the dummy value for the rest of the array, and avoid
> Obj.magic -- however this is very inefficient, since
> the dummy would have to be changed in many places
> whenever the first entry in the array changed

I didn't mean to change the dummy value all the time! Just take the first 
value as the dummy value, and keep it even if the first entry in the array 
changes. This will work fine for small values. If you are planning to put 
huge values in the array, I really think that the overhead of using an 'a 
option array is insignificant compared to the GC overhead.

> (and that isn't just a store -- there is a write-barrier
> to think about .. :)
>
> That won't happen in Buffer because you can't modify it,
> but it must be allowed in more general variable length
> mutable array.

What do you mean?

-- 
Stephane Glondu.