On Mon, Jun 04, 2007 at 12:32:33PM -0400, Jonathan S. Shapiro wrote: > On Mon, 2007-06-04 at 12:15 -0400, Swaroop Sridhar wrote: > > Even I thought the closed variable is copied by value. This is exactly > > similar to the r-value getting copied as a result of being passed > > by-value to closure-construction operator. > > Umm. No. Let me explain in more detail: > > (define (f x:(by-reference (mutable T))) > (lambda (y) (+ x y)) > > Note that x is captured by an escaping closure. In the "copy on close" > proposal, it would be required that the 'x' stored within the closure > would point at a *duplicate* of the original argument that resides in > the heap. That is: the closure formation code would be required to DUP > the 'x' at closure formation time. > > This can lead to very surprising results, because the conditions under > which such a DUP might occur are not visibly obvious to the programmer.
So with this code there's going to be an implicit DUP of whatever is referenced by the 'x' parameter? It will keep everything type-safe but I'm not sure if this would ever be considered expected (or, worst-case, even useful) behaviour. Maybe we're thinking this will be used in different ways! > > In BitC, the de-constructed value of a tagged union (resulting from > > a switch -- see `x' below) is not a first class entity. It can only > > appear on the LHS of a selection (.) operator, and it is a *copy* of > > the original union value on which we are performing a switch. > > Hmm. Yes. That is a subtlety that I had forgotten about, and it fully > addresses the concern. I'd completely forgotten about that as well. Is the reason you have a DUP operator and no address-of operator mainly to reduce aliasing then? > > I am missing the safety problem you are referring to, that would > > require a stronger static analysis. > > The C++ safety problem results from other features interacting with > by-reference parameters. The C++ analogy was a bad one, sorry. My union example was about getting a reference to the member of a union's leg without deconstructing it first. This obviously doesn't apply to BitC. Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
