[bitc-dev] Capture problem with by-ref

[Jonathan S. Shapiro]

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