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
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
