[bitc-dev] Capture problem with by-ref

[Swaroop Sridhar]

Jonathan S. Shapiro wrote:
> 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.

I had missed what you said above the list of alternatives by the time I
read all the mails. I apologize.


> 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.

Unfortunately, I don't see this problem. If the inner function only uses 
the by-ref argument as an rvalue as in:

(define (outer x:(by-ref 'a))
   (lambda (y) x))

It is as if this function were written as (the closure-converted
version):

(define (outer x:(by-ref 'a))
   (MAKE-CLOSURE (lambda (y x1) x1) x))

or by using conventional environments as:

(defstruct inner-closure
     fnxn: (fn ('b 'a) 'a)
     env: 'a)

(define inner-lambda (lambda (y x1) x1))
(define (outer x:(by-ref 'a))
    (inner-closure inner-lambda x))

The by-ref-nesss and (top-level) mutability is lost here because of the
copy operation when x is passed as a by-value argument to MAKE-CLOSURE
or the inner-closure constructor.

Further, we never form a type such as (by-ref (by-ref t)).

> However, I am a bit concerned that this rule is a bit ad-hoc from the
> standpoint of formal semantics specification...

The formal specification is certainly more complicated with by-ref than
without it. However, I am not sure if it will make it ad-hoc. If
make-closure is a step of computation, then the by-ref argument is
automatically dereferenced as a consequence of providing it as an
argument to the MAKE-CLOSURE constructor.

Swaroop.