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
