On Wed, Mar 11, 2009 at 9:22 AM, Gelf Mrogen <[email protected]> wrote: > 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: > > 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:
Generically, I think that what is needed here is something like linear types. Basically, you need to know that (a) the value has not escaped, and (b) at the point where the const-ness is imposed, you are looking at the only live alias. This can be done, and in principle we know how to do the necessary typing, but it's beyond what I want to try to tackle right now. Just to give a trivial, kludgy intuition, though, in: (let ((v (make-vector 5 (mutable #\c)))) (init-the-vector v) ; where v is somehow known not to escape (const v)) we could introduce a new version of const that could legally implement this. Region typing can determine that v does not escape, and it's evident here that v is not live at the end of the let. The part of this that is slightly complicated here is that we actually don't have a way to implement the down-cast of the vector elements to const; the const metaconstructor's effect stops at the ref boundary, which in this case is immediately. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
