On 6 January 2013 10:44, Jonathan S. Shapiro <[email protected]> wrote: > Mutabiity inference is probably the most complex thing we attempted in BitC, > and we got it wrong. I think the *issues* aren't hard to summarize: > > 1. When a constituent field of an object is "immutable", but the entire > object is not, what does that mean? The choices are: (a) it prevents any > assignment that would cause the corresponding *location* to change, or (b) > the property holds only for the lifetime of the containing object. In the > presence of unboxed types and concurrency, these two definitions are very, > very different.
I think I like (b) for views (especially linear views), and (a) otherwise. (b) appears to allow me to write custom allocators. I can allocate the space on the stack for a FooIterator once and initialise it several times. In the loop header I say foo_iterator = foo_iterator.next(); and if the type system has ensured that no references to foo_iterator have escaped, I (and my callees) know that those fields are fixed on the entire domain of the loop body. The semantics of (b) otherwise appear to fit a C++ style const model and so probably aren't very useful. It would be nice to have something analagous to Java's final. If the region of the location does not escape to callees, (b) induces a reverse-dataflow relation, ensuring that the contents of the field does not change across subroutine calls, but (a) goes in both directions, ensuring that the caller can't go changing the value either. That so many languages do (a) appears to suggest that this is a very useful concept. > The cases that are compile-time invariant [shallowly or deeply] seem > pretty straightforward. The cases that involve mixed invariance seem more > complicated. So some questions: > > 1. Is this worth it? It seems to be driven by the desire to mix imperative > and pure programming without an explosion of type definition variations (due > to case analysis getting embedded at the type level). I think so. Recursive data is one example, there are tricks for doing it locally in many functional languages (and otherwise laziness helps), but sometimes you really want a value with a field that you will be expected to calculate much, much later. -- William Leslie _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
