<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Jul 30, 2008 at 12:06 AM, Colin Putney <span dir="ltr"><<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:<br>
<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 :) ).<br>
</blockquote>
<br></div>
I'm all for general immutability support in the VM.<br>
<br>
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).</blockquote>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Once strings are immutable, interning them is a useful space optimization, and that *would* make symbols redundant.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Clearly there are huge compatibility issues here, but it's a reasonable thing to consider if building a system from scratch.</blockquote>
<div><br></div><div>I'll grant you that. But having considered it I'd ditch it pretty quickly. Per-object immutability is much more useful :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><font color="#888888">
<br>
Colin<br>
</font></blockquote></div><br></div>