On Fri, Aug 1, 2008 at 5:13 PM, stephane ducasse
<stephane.ducasse at free.fr> wrote:
>
> On Jul 30, 2008, at 9:06 AM, Colin Putney wrote:
>
>>
>> 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).
>
> for example.
>>
>>
>> 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

It was already pointed out that interning *all* strings is *not* going
to save space.  What is wrong with having symbols and strings?  I find
symbols to be one of the great insights of Smalltalk [1] and Java's
string handling to be one of its worst features.

[1] The great thing about it is instead of making some meaningless
number, and then a macro that replaces your readable string with that
number (as one must do in C, etc) you just use your meaningful string
as a symbol and it can be the same cost as a meaningless number (since
the native code need only look at the underlying address)