The future of "frozen" types as the number of CPU cores increases

[Alf P. Steinbach]

* Paul Rubin:
> John Nagle <nagle at animats.com> writes:
>>> However, things have changed, and lists and tuple *are* effectively
>>> mutable and hashable versions of each other...
>>    It's the concurrency aspect of this that interests me, though.
>> A language with immutable objects can potentially handle concurrency
>> more safely than one where everything is potentially mutable.
>> The language knows what can't change, which simplifies locking.
> 
> I wonder how well that applies to tuples containing mutable objects,
> e.g.  t = ([1,2], [3,4])

One would need a collection type that's immutable "all the way".

Current frozen types don't have that.

However, there's also the question of the immutability of what names refer to. 
It seems to me that this means that the compiler can't really assume very much 
without very deep analysis. And so, if it boils down to the programmer applying 
assumptions about mutability/constantness, then types may not be The Answer.


Cheers,

- Alf