2008/7/30 Colin Putney <cputney@wiresong.ca>:

>
> On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
>
>> BTW, immutability involves primitive error codes and I will be introducing
>> primitive error codes, because the performance hit is essentially zero and
>> there is no backward compatibility issue (strange but true :) ).
>
> I'm all for general immutability support in the VM.
>
> I suspect, though, that this isn't what Stéphane was driving at. Immutable
> strings is kind of a language-level thing, and could be done without VM
> support.  One way would be to factor out a MutableString class and keep it
> distinct from regular strings. Going further, we could just remove the
> mutation protocol and require all string creation to be either stream-based
> or functional (ie, producing new strings rather than mutating existing
> ones).
>
> Once strings are immutable, interning them is a useful space optimization,
> and that *would* make symbols redundant.
>
> Clearly there are huge compatibility issues here, but it's a reasonable
> thing to consider if building a system from scratch.
>
> Colin
>

+1
i think we can live without immutable support from VM.
Arrays and Strings can be subclassed with disabled mutation methods.
And then compiler could use these classes for literals.
Except from compiler support, where else we need immutability?
Do we need a generic immutability , which would allow to flag any
object from being changed?
This is useful feature, but i doubt that alone, it could improve code
quality or solve security issues so easily.