I'll add: generalizing this to arbitrary immutable value construction by 
mutable means would be nice.




--- On Wed, 3/11/09, Geoffrey Irving <[email protected]> wrote:

From: Geoffrey Irving <[email protected]>
Subject: [bitc-dev] temporarily mutable arrays
To: "Discussions about the BitC language" <[email protected]>
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?

Thanks,
Geoffrey
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev



      
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to