[bitc-dev] CLEANUP: pragmatics of closure conversion

[Jonathan S. Shapiro]

On Fri, 2008-07-18 at 15:23 -0400, Swaroop Sridhar wrote:
> Jonathan S. Shapiro wrote:
> > Rules: Given a lambda form L and some /id/ that is free in L:
> > 
> >   PHASE I: INITIAL CLOSURE CONSTRUCTION
> > 
> >   1. If /id/ resolves to a globally defined identifier, stop. No
> >      globally resolved identifier is ever inserted into a closure
> >      record.
> >   2. If /id/ is locally bound:
> >      A. if /id/ is mutable, it must be heap-converted, and the reference
> >         to the heap-converted object must be included in the closure
> >         record.
> 
> Just to be super-precise, the /id/ must be heap converted only if it is
> shallowly mutable. If the mutability is within a reference in the value
> denoted by /id/ right?

Yes. If (RefType? id) then /id/ does not need to be heap converted. Good
catch.

> >      B. if /id/ is non-mutable but of non-reference type, it must be
> >         heap-converted and the reference to the heap-converted object
> >         must be included in the closure record.
> >      C. if /id/ is non-mutable and of reference type, a copy of /id/
> >         must be included in the closure record.
> 
> Is the fact that the immutable unboxed values are closure converted as a
> matter optimization (so that the closure record is small)?

If /id/ is shallowly immutable it is sufficient to make a copy of /id/
without heap conversion.

But this is not merely a matter of optimization. The language must
specify unambiguously which things induce heap allocation.

>    Otherwise, we can place copies of immutable unboxed values in the
>    closure. That is, handle B and C the same way.

Yes. That is the correct thing to do.

shap