On Mon, 2007-06-04 at 12:15 -0400, Swaroop Sridhar wrote:
> >
> > OK, I think I completely missed what you meant when you said copying
> > the "by-reference value".
>
> 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.
> > I've just noticed a problem with these by-references values though.
> > That of calling a "by-reference" method with the reference to an element
> > of a union and changing the tag of the union invalidating the type of
> > the element inside the "by-reference" function. I can only think of
> > very contrived bits of code that would trigger it, but it would break
> > type safety.
>
> I did not understand this problem, can you please explain. 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.
> In fact, not all
> values / expressions can be used in a pass-by reference position (ex:
> the literal 1 cannot be passed by reference).
This is another problem case that I had not considered, but I do not
agree with the proposed solution. If the parameter type is
(BY-REFERENCE (MUTABLE T))
then prohibiting a literal argument is the right thing to do, because it
is almost certainly a programmer error. However, if the parameter type
is instead:
(BY-REFERENCE (IMMUTABLE T))
then the literal can be forced into a temporary without loss of meaning
or common sense. This is what C++ does when a temporary or a literal is
passed at a parameter position expecting a const &, and it seems to work
out very well.
> This proposal does not introduce the generic & operator. We can only
> have a down-flow of stack addresses passed by reference as far as I can
> see.
Well, that was exactly my intention, and given how nasty the whole
STACK-REF thing turned out to be, I am glad that I seem to have gotten
this one right for a change. :-)
> This can be thought of as a degenerate case of region-analysis.
Yes.
> 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.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
