On Tue, 2008-03-11 at 11:50 -0400, Swaroop Sridhar wrote: > Jonathan S. Shapiro wrote: > > I am inclined to prohibit this by declaring that no by-ref argument is > > permitted to be captured by a closure. The alternatives are: > > > > 1. Remove BY-REF, but I don't want to do that because it is extremely > > useful. > > > > 2. Force the compiler to heapify any stack-based argument value that > > is passed to a BY-REF formal parameter, effectively re-writing the > > BY-REF as REF. > > > > Note that there is no issue here for objects that are already > > heap-based. It is only stack frame capture that is the source of > > concern. > > I see the problem. There is actually another solution we can consider, > which is to not permit capture of by-ref arguments since this is a > form of escape.
Yes. That was my primary suggestion above. > The question now is, what if the example were written as: > > (define (outer x1:(by-ref 'a) x2:(by-ref 'a)) > (lambda (y) > (set! x1 x2))) > > Now, x1 is used as an l-value, and this will lead to the escape of the > pointer corresponding to the by-ref argument. > > So, I think we can say that the by-ref arguments cannot be used in > an inner-lambda at an lvalue position. That isn't good enough. Even if it is used in an r-value position, a formal parameter of type (by-ref (mutable 'a)) can still alias a stack frame. I believe the best answer is to prohibit captured by-ref formal parameters. However, I am a bit concerned that this rule is a bit ad-hoc from the standpoint of formal semantics specification... shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
