[bitc-dev] Capture problem with by-ref

[Jonathan S. Shapiro]

On Wed, 2008-03-12 at 18:24 -0400, Swaroop Sridhar wrote:
> Jonathan S. Shapiro wrote:
> > On Wed, 2008-03-12 at 14:14 -0400, Swaroop Sridhar wrote:
> > Unfortunately, your statement [2] is wrong. Counter-example:
> > 
> >   (define (g)
> >     (let ((local : (mutable int32)  1)
> >       (letrec ((closure
> >                  ((lambda (lref:(by-ref (mutable 'a)))
> >                     (lambda (x)
> >                       (set! lref (+ lref 1))
> >                       (+ lref x))) local)))
> >         (pair (closure 1) (closure 1)))))
> > 
> > If your theory were correct, the result should be (2, 2). But it is
> > clear here that the outer lambda has closed over "local" by means of
> > application, and the correct answer must be (2, 3).
> 
> I don't see why (2) is wrong here. The inner lambda (with parameter x)
> escapes because it is being returned, so (1) is not satisfied). It
> assigns a non-local by-ref variable lref so (2) is not satisfied. So,
> this definition would be rejected by the compiler.

(2) is wrong here because we are looking for a pair, so I don't know how
to respond to this. Can you clarify?

> > SIMPLE:  No captured formal parameter of BY-REF type is permitted to
> >          escape.
> > 
> > REFINED: A BY-REF parameter can be captured and allowed to escape
> >          exactly if the compiler can statically determine that the
> >          aliased actual parameter can be heapified.
> > 
>
> Regardless of my above paragraph, I agree that the simple solution is
> probably best and sufficient to solve the problem.

Just to publicly record our phone conversation, our short-term decision
on this was to adopt:

  SIMPLEST: no BY-REF paramater can be captured by a closure [whether
     or not the closure escapes].

This is purely a matter of expedience. The issue is that we do not
currently have any implementation of closure escape analysis to use, and
we don't want that to delay the implementation.

shap