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