Wed, 14 May 1997 20:17:31 -0400 (EDT)
HB> This is an excellent idea, for those arrays that can be initialized
HB> with a generator.
HB> potential problems:
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. :)