On Wed, Jul 30, 2008 at 12:06 AM, Colin Putney <cputney at wiresong.ca> 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).


This seems like a good idea and I tried it in the late 80's in BrouHaHa but
it ends up being extremely clumsy.  For example, if 'foo' is an instance of
ImmutableString then every time one stores a mutable string one has to store
it as e.g. 'foo' asString or as String with: $f with: $o with: $o etc.
 ALternatively if 'foo' is an instance of String (mutable) then when you
print out a literal it prints as 'foo' asImmutableString, etc.  Or one deals
with the ambiguity.  So IMO having immtability be a property of the class
rather than the instance introduces ugly complications.

Once strings are immutable, interning them is a useful space optimization,
> and that *would* make symbols redundant.


Its not clear it makes them redundant.  For example, the reason why, in
VisualWorks, there is no shared pool of the ByteArrays used to make up the
bytes part of CompiledMethods is that the table would take up more space
than it would save because there is so little duplication of bytecode
vectors.  Symbols have to be unique so we have to pay space for a table.
 But from the VW experience I woud doubt very much whether uniqueing all
strings would be a space win.  Symbols are a subset of strings which are
widely shared because they are used for message selectors and certain other
common names (globals, method protocols etc).  Because of this shared use
they have more references per symbol than strings do.  Further there is a
significant lookup cost for uniqueing symbols, higher once one makes the
lookup thread-safe :)  Its not clear one would want to pay that cost for
strings in e.g. package loading, distributed object marshalllng, DB
interfaces, etc, etc.

Another thing is that were one to implement selector namespaces a la David
Simmons' S# Symbols become much richer objects than strings and having
unique strings would only be part of the story.  You'd still need Symbol
even if each symbol referenced a unique string.


Clearly there are huge compatibility issues here, but it's a reasonable
> thing to consider if building a system from scratch.


I'll grant you that.  But having considered it I'd ditch it pretty quickly.
 Per-object immutability is much more useful :)


>
>
> Colin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080730/b4fd0a12/attachment.htm