I *really* want to get a version of BitC done, and at this point I'm willing to compromise on a whole bunch of things. By "done" I mean getting a working version we can start using, even if some of the features we *do* understand aren't quite there yet. The two outstanding problems are mutability and instance resolution.
In spite of appearances, we have made some progress on the mutability front. 1. It is now clear that the difference between boxed and unboxed types really *is* semantic, and that in consequence the syntactic "hole" for expressing mutability that is associated with boxed types is actually important. 2. We've recognized a distinction between integrity-driven concerns and mutability-driven concerns. I think we are down to a few cases that we clearly understand, and a bunch of cases that we don't have a handle on yet. I suggest that perhaps we should get something we can use and defer the ugly cases for further thought. In what follows, please set aside any previous definitions of terms that we may have used, since I need to get stable bindings established for the terms. N.B. that I am probably using the term "location" here improperly; let's defer that until we have agreement on this part first. Here are the issues that I think we understand: 1. We have consensus that "init only" or "read only" fields are the same thing, and that in the context of fields these keywords describe an integrity property. The lifetime of the guarantee expires when the containing object is overwritten. 2. We seem to agree that there is something else, which I will call "immutable". This property guarantees that a location cannot be modified through *any* alias or name, and that no *new* alias or name can be formed that would permit it to be modified. The lifetime of the guarantee expires when the program arrives at a sequence point (an execution state) from which the location is no longer reachable. 3. Finally, we seem to agree that there is a distinction between "it cannot be mutated" and "I cannot mutate it". That is: a difference between a reference to immutable data and a non-mutating reference to data. It is not clear whether we wish to exploit this distinction. 4. For both immutable references and non-mutating references, we can distinguish clearly between shallow and deep restrictions. 5. We know that the introduction of field-wise mutability restrictions creates some challenging subtyping issues at copy boundaries. These may or may not be solvable, but we don't have a suitable algebra for them now. 6. It is not fully clear [to me] whether immutability is part of type. If it is, then an unboxed instance of an immutable type may not be named by an unboxed alias[*] having a mutable component. 7. We know that there are certain contexts in which the uniqueness of a pointer can be established (even in the absence of general uniqueness typing or linear typing), and that certain important permission-reducing operations are legal exactly when uniqueness can be established. 8. We know that inner references, if desirable, can be simulated in our most uncooperative target runtime of interest. [*] By "unboxed alias" I mean a dot-separated identifier path such as "a.b.c" in which no element has boxed type. That is: the unboxed portion of an alias is that portion appearing to the right of the rightmost box boundary. I want to pause here and ask for confirmation. First, does everybody agree that we really do understand the items I have enumerated? Second, are there relevant issues that I have failed to enumerate that we now have a consensus on? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
