Or if you're performing whole program compilation, you can require that
any field that *may* be captured by a ref, must be indirected to a
heap-based cell ala ML refs. When capturing a ref, just return this cell.
The problem with your solution is that I don't think it's CLI safe
unless the VM is running under "full trust". I believe the VM will
prevent you from accessing the private fields of another object since
this code is not verifiable (unless all fields are public?).
Sandro
On 24/03/2011 2:18 AM, Jonathan S. Shapiro wrote:
> Ah the glory that is CLI! If you are willing to sufficiently commit
> yourself to barf-worthy solutions, you can accomplish almost anything. I
> just figured out how to do a semantically conforming implementation of
> inner references. If you have recently eaten, and are not possessed of a
> truly iron stomach, you'll definitely want to come back to this note later.
>
>
> This technique is required exactly if (a) you take a
> liveness-constrained reference, and (b) that reference is /captured/. It
> /may/ also be required in some conservative corner cases, but offhand I
> can't think of any.
>
> This technique does /not/ work on anything that is stack allocated. If a
> reference of this form is captured, it is necessary to spill the
> stack-allocated item to the heap. This is essentially the same problem
> that we already have for closures.
>
> So with those two caveats:
>
> We define an abstract base class InnerReference<T>. This class has
> abstract virtual member functions
>
> T get()
> void set(T&)
>
> Wherever an inner reference is captured in BitC, it is necessarily of
> the form a.b..y.z, where 'a' is some reference type and "b...y.Z" is a
> compile-time path of identifiers naming the field being captured. Note
> that none of the intermediate fields "b...y.z" has reference type.
>
> When a reference to such a field is captured, we introduce an anonymous
> concrete class that is a subclass of InnerReference<T>. This concrete
> class encapsulates 'a', and provides implementations of get() and set()
> as follows:
>
> T get() { return a.b....y.z; }
> void set(T& t) { a.b...y.z = t; }
>
> This anonymous class is instantiated at the point where the inner
> reference is captured, and the CLI type given to the resulting inner
> reference is InnerReference<T>.
>
> Two instances of InnerReference<T> are considered EQ if (1) they
> encapsulate the same outer reference 'a', and (2) they apply the same
> relative path of identifiers b...y.z.
>
>
> How's that for barf-worthy! Thank God it will only get called on in rare
> cases!
>
>
> shap, who needs to go clean the yuck out of his keyboard now.
>
>
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
