>we get to rely on the fact that the reference to the object under construction has not escaped into the rest of the program state
This is where effect tracking becomes useful. If the mutable object escapes, it is reflected in the type signature, so a type level assertion that the unique phantom type for the object in question is not in the effect set prevents leakage. Keean. On 10 February 2015 at 22:01, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 10, 2015 at 12:13 PM, Keean Schupke <[email protected]> wrote: > >> So if an immutable list, and a mutable hash-table can both have the same >> 'extensible' interface, and the generic comprehension can be defined in >> terms of this, what is the problem? I don't see the need to have two >> syntaxes one for a comprehension that writes to a mutable data-structure, >> and one that writes to an immutable data-structure. >> > > I agree. And it's fairly easy to write a type class accordingly. > > >> In any case immutable is debatable. There is actually a write to memory, >> which mutates the memory cell in the memory array even in the list case, so >> there is really no such thing as immutable. What there is, is a 'special' >> construction time when mutation is allowed, and then the object is 'frozen' >> and becomes immutable. In this sense we can consider any mutable data >> structure to simply still be in construction, when we are finished we can >> freeze it, and it becomes immutable just like a list. This can be >> particularly elegant with comprehensions, when we might allow the >> comprehension to mutate the result object, but have it frozen immediately. >> > > I agree with this too, but it's a little subtle. In ML or OCaml, which > have no user-defined construction, we get to rely on the fact that the > reference to the object under construction has not escaped into the rest of > the program state. In the case of comprehensions, I'm not yet convinced > that is true. I'm not saying it isn't. I'm just saying we need to think > that one through and make sure that it actually holds. > > > shap > > _______________________________________________ > 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
