Mutation

[BRIAN SPILSBURY]

HB> This is an excellent idea, for those arrays that can be initialized
HB> with a generator.
HB> 
HB> potential problems:
HB> 
HB> How do you actually implement 'make-array' ?  (This _is_ a reflective
HB> system, isn't it?)  Presumably, you have to allocate a piece of
HB> storage, and then iterate through the array, calling the generator for
HB> each element.  Due to the possibility of side-effects, you have to
HB> define the order -- e.g., 1st to last -- but even more importantly,
HB> what does the array look like to the GC, since a GC can happen within
HB> one of the calls to the generator?

I would have expected the array-under-construction to be bound in some
way to the thread's context - precice/conservative stack collection,
at the least.

HB> This is why I lean towards the 'linear' solution: allocate a 'linear'
HB> piece of storage and fill it in as before.  Since it is 'linear'
HB> (refcount==1), no one else can even see that it exists.  Since it has
HB> only one pointer, there is no possibility of a 'dangling pointer' when
HB> it is converted (frozen) from a mutable linear type into a functional
HB> type.  If one of the generator calls craps out with an exception, the
HB> usual 'unwind-protect' sort of behavior built into every linear type
HB> kicks in to make sure that the linear object is freed.

Hmm, I may be missing the picture here, but I was imagining that
make-array would create the array, and then without telling anyone what it was
use a generator/initial-elements arg to fill it, freeze it, and then return it.

This sounds almost the same as what you're saying there, which is why
I'm wondering. :)

Brian