[bitc-dev] temporarily mutable arrays
gelfmrogen at yahoo.com
Wed Mar 11 10:22:48 EDT 2009
I'll add: generalizing this to arbitrary immutable value construction by mutable means would be nice.
--- On Wed, 3/11/09, Geoffrey Irving <irving at naml.us> wrote:
From: Geoffrey Irving <irving at naml.us>
Subject: [bitc-dev] temporarily mutable arrays
To: "Discussions about the BitC language" <bitc-dev at coyotos.org>
Date: Wednesday, March 11, 2009, 1:56 PM
Most imperative operations in numerical code (my own, at least)
involve incremental construction of vectors, sometimes in random
access order. In many cases these arrays aren't modified once they
are created. Currently each location in BitC memory is either
permanently mutable or permanently immutable, which means that an
array constructed using imperative operations must be copied in order
to become immutable. How difficult would it be to relax this
restriction enough to allow the following pattern:
f : vector int -> ()
freeze : mutable 'a -> 'a # with escape restrictions
let a = make-vector 100 0
for i in range(100):
a[i] = i
f (freeze a)
where the "freeze" function doesn't copy any data, just unsets the
mutability flag and returns its argument. I.e.,
1. Construct a vector referenced only from the stack.
2. Modify it using imperative operations.
3. Explicitly coerce the array type from mutable to immutable.
Note: this isn't a feature request, just a technical question about
how difficult the type system extension would be. Currently, I'm
imagining this requires
1. Enough effect typing to know that "make-vector" doesn't store an
extra reference to the return value, which could be handled by adding
a "modifies existing memory" bit to the effect lattice.
2. Enough type analysis to know that the vector doesn't store a
reference to itself (trivial in this case).
3. Enough escape analysis (taking into account by-ref and the like) to
know no extra references to "a" are created after its construction.
I believe BitC already has (3) and will very quickly have the
machinery for (1). Is this picture correct?
bitc-dev mailing list
bitc-dev at coyotos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev