[bitc-dev] temporarily mutable arrays
Jonathan S. Shapiro
shap at eros-os.com
Wed Mar 11 11:47:03 EDT 2009
On Wed, Mar 11, 2009 at 9:22 AM, Gelf Mrogen <gelfmrogen at yahoo.com> wrote:
> 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:
> 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
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.
More information about the bitc-dev