Mutation

[Henry G. Baker]

> Regarding the use of mutation, isn't it pretty common once you start
> using arrays?  When doing large data analyses in Lisp, I've had to
> replace lists of numbers with typed arrays, and changed computations
> to all work in place so as to reduce garbage creation.  This is to
> increase efficiency, and often helps alot (can give a factor of 2 or 3
> speedup, or even make an intractible problem tractible).  What sort of
> effects are the anti-mutation proposals going to have on this?
> 
> -- 
> Harvey J. Stein

The problem with functional objects is indeed functional arrays.  You
have to have some way to initialize them.  One way to do this is to
have them start life as mutable arrays, and then at some point you
'freeze' them into immutable arrays.  The problem with this approach
is that it 'surprises' the person still holding onto a pointer to the
old 'mutable' array.  These semantics are very unpleasant because they
violate the constancy of type.

Another approach is to create a brand new functional array by copying
an existing mutable array.  This solves the problem of bad semantics,
but forces you to throw away and GC a perfectly good mutable array for
every immutable array.  So we have good semantics, but bad performance.

The third approach walks the tight-rope between the previous two
approaches.  The array starts life as a _linear_ array, which is
mutated in-place in order to initialize it.  Since linear objects
aren't recovered by the GC, the linear object's storage can be
immediately 'recycled' (by 'freezing') as the functional array itself,
which is already conveniently initialized.  Furthermore, since it is a
linear object, there cannot possibly be any other pointers to the
object, so good semantics are preserved.

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html