On Wed, Mar 23, 2011 at 4:23 PM, William ML Leslie < [email protected]> wrote:
> This is a copy, right? Which doesn't seem to suffer from the problem > you are trying to expose, but I think I can see what you mean. I can > take a reference to the target of $container.s$, and thus have a > reference to an immutable structure, and yet I can't talk about the > purity of the target in any way, because it depends on the mutability > of the path where it is stored, not the mutability of the object > referred to - information which does not appear in the type of the > reference I have. That is a tricky one. > Yes. That's *exactly* the issue, and very nicely stated. What we're hitting here is exactly the thing that got me into confusion with Swaroop: how do mutability restrictions compose across '.' (if at all)? If we adopt MarkM's integrity-oriented view, which is actually a perspective about permissions, the answer is that they do not compose. This is a reasonable way to think about init-only restrictions. In the *absence* of inner references, we also need not consider propagation for purposes of mutability. This is true because in the absence of inner references and unboxed value cannot be shared unless it is an "outermost" unboxed value (that is: the result of a box() operation), in which case it's name does not (by construction) contain '.'. But in the *presence* of inner references, matters are not so pleasant, and the whole mess becomes exposed. At that point, we are obliged to impose some containment constraints to preserve the semantics of purity. Given that .Net and some other key platforms do not even *support* inner references, it really might be the right decision to remove them entirely. Besides adding this information (the purity of the object referenced) > to the type of all references, I wonder if there are other solutions > that also don't sound completely arbitrary. > I think that purity does indeed need to be part of the reference target type. Either that, or it needs to be an inherent part of the target type at the time the type is defined. I'm trying to figure out which of those statements is true as we speak. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
