Hello
I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us? Then does it mean that we could get rid of symbols immutability does not imply unique identity.
Stef
On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse stephane.ducasse@free.frwrote:
Hello
I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?
Safety. One can no longer overwrite literals or methods (or anything else whose state you want to protect) accidentally.
Expressive power. One can use immutability as a write barrier in orthogonal persistence or distribution schemes (and other things) . One marks an object as immutable to indicate that it is persistent or distributed and its changes should be exported. The immutability scheme allows one to associate managers for specific objects that handle NoModificationErrors on a per-object basis. So if an object is immutable and has an appropriate manager that manager can temporarily enable immutablity for the object, allow the modification, communicate the modification (e.g. to a database or remote image) and then re-enable immutability. The framework allows an object to have multiple managers. (This is all standard Squeak and very similar to the code I wrote for VW. The VM code is also available from Cadence).
Then does it mean that we could get rid of symbols
immutability does not imply unique identity.
No. As you point out Symbols are unique and so immutable strings don't replace them. But it is nice to have immutable Symbols. e.g. try to do this in your Squeak image: #class pvtAt: 1 put: 0 asCharacter Scary :)
Stef
Hi Eliot,
Does that mean that you are introducing immutability in new Squeak VM you are working on? Well, that would be really nice!
Janko
Eliot Miranda wrote:
On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse <stephane.ducasse@free.fr mailto:stephane.ducasse@free.fr> wrote:
Hello I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?Safety. One can no longer overwrite literals or methods (or anything else whose state you want to protect) accidentally.
Expressive power. One can use immutability as a write barrier in orthogonal persistence or distribution schemes (and other things) . One marks an object as immutable to indicate that it is persistent or distributed and its changes should be exported. The immutability scheme allows one to associate managers for specific objects that handle NoModificationErrors on a per-object basis. So if an object is immutable and has an appropriate manager that manager can temporarily enable immutablity for the object, allow the modification, communicate the modification (e.g. to a database or remote image) and then re-enable immutability. The framework allows an object to have multiple managers. (This is all standard Squeak and very similar to the code I wrote for VW. The VM code is also available from Cadence).
Then does it mean that we could get rid of symbols immutability does not imply unique identity.No. As you point out Symbols are unique and so immutable strings don't replace them. But it is nice to have immutable Symbols. e.g. try to do this in your Squeak image: #class pvtAt: 1 put: 0 asCharacter Scary :)
Stef
On Tue, Jul 29, 2008 at 1:03 PM, Janko Mivšek janko.mivsek@eranova.siwrote:
Hi Eliot,
Does that mean that you are introducing immutability in new Squeak VM you are working on? Well, that would be really nice!
I think that's up to the community. There is a small performance hit (don't have measurements to hand but would expect it to be in the 2% to 4% range). What I'd like to do is modify Slang so that one can mix and match components to produce the VM you want. In the StackVM I'm working on I already have the ability to add a subclass that overrides methods in the superclass so NewObjectMemory organizes the young generation differently to ObjectMemory overriding a few methods. It should be easy to extend this to allow e.g. ImmutabilityInterpreter to override Interpreter and add immutability without having to rewrite the entire Interpreter class.
Then we don't have to commit to immutablity. People can experiment with it and then try to persuade the community that its a good idea (I do think its a good idea).
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 :) ).
Janko
Eliot Miranda wrote:
On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse < stephane.ducasse@free.fr mailto:stephane.ducasse@free.fr> wrote:
Hello
I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?
Safety. One can no longer overwrite literals or methods (or anything else whose state you want to protect) accidentally.
Expressive power. One can use immutability as a write barrier in orthogonal persistence or distribution schemes (and other things) . One marks an object as immutable to indicate that it is persistent or distributed and its changes should be exported. The immutability scheme allows one to associate managers for specific objects that handle NoModificationErrors on a per-object basis. So if an object is immutable and has an appropriate manager that manager can temporarily enable immutablity for the object, allow the modification, communicate the modification (e.g. to a database or remote image) and then re-enable immutability. The framework allows an object to have multiple managers. (This is all standard Squeak and very similar to the code I wrote for VW. The VM code is also available from Cadence).
Then does it mean that we could get rid of symbols immutability does not imply unique identity.
No. As you point out Symbols are unique and so immutable strings don't replace them. But it is nice to have immutable Symbols. e.g. try to do this in your Squeak image: #class pvtAt: 1 put: 0 asCharacter Scary :)
Stef
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
2008/7/29 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Jul 29, 2008 at 1:03 PM, Janko Mivšek janko.mivsek@eranova.si wrote:
Hi Eliot,
Does that mean that you are introducing immutability in new Squeak VM you are working on? Well, that would be really nice!
I think that's up to the community.
Wouldn't that break a lot of code? Like anything that does WriteStream on a String like #streamContents: ?
Cheers Philippe
Philippe Marschall schrieb:
2008/7/29 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Jul 29, 2008 at 1:03 PM, Janko Mivšek janko.mivsek@eranova.si wrote:
Hi Eliot,
Does that mean that you are introducing immutability in new Squeak VM you are working on? Well, that would be really nice!
I think that's up to the community.
Wouldn't that break a lot of code? Like anything that does WriteStream on a String like #streamContents: ?
No, unless you're doing WriteStream on: '' which you should not do anyway. Normal Strings (those that are created with #new: or with copying) are mutable, just as they are now. In general, any code that breaks when the immutability of literals is ensured by the VM was broken to begin with...
Cheers, Hans-Martin
On Tue, Jul 29, 2008 at 2:11 PM, Hans-Martin Mosner hmm@heeg.de wrote:
Philippe Marschall schrieb:
2008/7/29 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Jul 29, 2008 at 1:03 PM, Janko Mivšek janko.mivsek@eranova.si wrote:
Hi Eliot,
Does that mean that you are introducing immutability in new Squeak VM
you
are working on? Well, that would be really nice!
I think that's up to the community.
Wouldn't that break a lot of code? Like anything that does WriteStream on a String like #streamContents: ?
No, unless you're doing WriteStream on: '' which you should not do anyway. Normal Strings (those that are created with #new: or with copying) are mutable, just as they are now. In general, any code that breaks when the immutability of literals is ensured by the VM was broken to begin with...
+1.
Its trivial to fix such code. e.g. if you have (ReadWriteStream with: 'The date is ') print: Date today; contents you simply change it to (ReadWriteStream with: 'The date is ' copy) print: Date today; contents and you're done.
Some developers in the VW community complained when we introduced immutability in 2002 about exactly these cases. But the fuss soon died down as people realised that indeed their code was safer with the change.
Cheers, Hans-Martin
Eliot Miranda wrote:
> Wouldn't that break a lot of code? Like anything that does WriteStream > on a String like #streamContents: ? > No, unless you're doing WriteStream on: '' which you should not do anyway. Normal Strings (those that are created with #new: or with copying) are mutable, just as they are now. In general, any code that breaks when the immutability of literals is ensured by the VM was broken to begin with...+1.
Its trivial to fix such code. e.g. if you have (ReadWriteStream with: 'The date is ') print: Date today; contents you simply change it to (ReadWriteStream with: 'The date is ' copy) print: Date today; contents and you're done.
Some developers in the VW community complained when we introduced immutability in 2002 about exactly these cases. But the fuss soon died down as people realised that indeed their code was safer with the change.
I can confirm that. Changes to the existing code due to the immutability were indeed rare. In my case mostly changing WriteStrean on: '' to WriteStream on: String new.
Best regards JAnko
On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
What I'd like to do is modify Slang so that one can mix and match components to produce the VM you want. In the StackVM I'm working on I already have the ability to add a subclass that overrides methods in the superclass so NewObjectMemory organizes the young generation differently to ObjectMemory overriding a few methods. It should be easy to extend this to allow e.g. ImmutabilityInterpreter to override Interpreter and add immutability without having to rewrite the entire Interpreter class.
I'm fairly sure that should have worked without any extra work since it is essentially how the codegen works anyway. What *doesn't* work is adding subclass and being able to use 'super' to only slightly modify the superclass code. I tried to get it working some years ago in an attempt to make it easy to implement OS specific plugin classes more easily but it drove me too close to the edge of insanity for my liking. If you've got *that* working I'd be very pleased.
Another aspect of pick'n'mix I'd like to see working is having all the parts of the vm in plugin (or plugin-like) modules. Why insist on having the GC irrevocably bound into the core (just for one example)? Why not have a system that can startup with no GC code; let the image's policy decide which GC plugin to load dependant upon need. An ephemeral app invoked to do a tiny job and quit may need no GC functionality at all so why waste space and setup time? A server app might want to use a much more sophisticated GC than our typical desktop system. Or perhaps the system should start up and run as a simple interpreter for a while until a policy has decided that Eliot's translator plugin should be loaded. And so on.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Soft rock
On Tue, Jul 29, 2008 at 2:51 PM, tim Rowledge tim@rowledge.org wrote:
On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
What I'd like to do is modify Slang so that one can mix and match components to produce the VM you want. In the StackVM I'm working on I already have the ability to add a subclass that overrides methods in the superclass so NewObjectMemory organizes the young generation differently to ObjectMemory overriding a few methods. It should be easy to extend this to allow e.g. ImmutabilityInterpreter to override Interpreter and add immutability without having to rewrite the entire Interpreter class.
I'm fairly sure that should have worked without any extra work since it is essentially how the codegen works anyway. What *doesn't* work is adding subclass and being able to use 'super' to only slightly modify the superclass code. I tried to get it working some years ago in an attempt to make it easy to implement OS specific plugin classes more easily but it drove me too close to the edge of insanity for my liking. If you've got *that* working I'd be very pleased.
The code generator I started with complains if the subclass redefines a method. Arguably this is a useful error check. So I modified the code generator to allow a subclass to explicitly remove superclass methods before adding its own. Trivial but effective.
Super is a different thing. I don't think there's any conceptual difficulty. Its simply another invocation of inlining. But the code generator's dictionaries of selector to method would have to be elaborated and its something I can do without for now.
Another aspect of pick'n'mix I'd like to see working is having all the parts
of the vm in plugin (or plugin-like) modules. Why insist on having the GC irrevocably bound into the core (just for one example)? Why not have a system that can startup with no GC code; let the image's policy decide which GC plugin to load dependant upon need. An ephemeral app invoked to do a tiny job and quit may need no GC functionality at all so why waste space and setup time? A server app might want to use a much more sophisticated GC than our typical desktop system. Or perhaps the system should start up and run as a simple interpreter for a while until a policy has decided that Eliot's translator plugin should be loaded. And so on.
Yep. Makes sense.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Soft rock
On 29-Jul-08, at 2:57 PM, Eliot Miranda wrote: [snip]
The code generator I started with complains if the subclass redefines a method. Arguably this is a useful error check. So I modified the code generator to allow a subclass to explicitly remove superclass methods before adding its own. Trivial but effective.
OK, yup, that would do it. I had forgotten that complaint.
Super is a different thing. I don't think there's any conceptual difficulty. Its simply another invocation of inlining. But the code generator's dictionaries of selector to method would have to be elaborated and its something I can do without for now.
Exactly. It ought to work by having some better dictionary of selectors. Can't remember what I tried (it was about 5 years ago now) but I had a great deal of practical trouble with it.
Another aspect of pick'n'mix I'd like to see working is having all the parts of the vm in plugin (or plugin-like) modules.
[snip]
Yep. Makes sense.
I like to think so. One of the first things would be to make Interpreter not be a subclass of ObjectMemory anymore.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- RIGOR MORRIS - The cat is dead
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
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.
On Wed, Jul 30, 2008 at 2:16 AM, Igor Stasenko siguctua@gmail.com wrote:
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.
No one is saying its a magic bullet. But it is an important element in code quality and security.
For one advantage, take a careful look at GemStone implementations in contexts where there is per-object immutability and where there isn't. GemStone's run-time is much simpler when there is per-object immutability support.
I'm curious why you're so against this. Do realise the modifications to the VM are pretty small and well-contained, and the performance overhead very small. Also realise that VW and VA do very well with it.
2008/7/30 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Jul 30, 2008 at 2:16 AM, Igor Stasenko siguctua@gmail.com wrote:
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.
No one is saying its a magic bullet. But it is an important element in code quality and security. For one advantage, take a careful look at GemStone implementations in contexts where there is per-object immutability and where there isn't. GemStone's run-time is much simpler when there is per-object immutability support. I'm curious why you're so against this. Do realise the modifications to the VM are pretty small and well-contained, and the performance overhead very small. Also realise that VW and VA do very well with it.
Agreed, OODBs could use an immutability bit for own purposes - like putting a write barrier on objects and then handle objects mutation to track their changes during transaction. I never worked with GemStone, but have some experience with Magma, and its using a 'hacky' way by changing an object's class to put a write barrier on objects. So, it is possible to do the same without immutable bit. And also, it is more precise , because there can be many reasons why you get a NoModificationError (it can be a simple programming error) , while if you catching it with write barrier - you definitely know that it is what you expected and can deal with it properly.
And if system allows marking object back to be mutable? Then how you could really tell that particular object is never modified during its lifetime? I think it should be sealed by behavior, by preventing any methods, which can modify an instance, to appear in class. So, the only real thing which can guarantee that given object remain unchanged during its lifetime is a class. An immutability bit is much worse thing comparing to this.
And second, its against the spirit of smalltalk. Smalltalk is one of the languages, where it tries to implement all things through behavior, not through using different VM/language magic intrinsics. It is not a problem, what VM having or not having an immutablity bit, its a problem, that current kernel classes and/or collections designed without looking at possible use cases where user wants to prevent object from being changed during its lifetime. So, maybe we should think how to refactor these classes instead of including one more magic thing?
On Thu, 31 Jul 2008 21:28:03 +0200, Igor Stasenko wrote:
...
I think it should be sealed by behavior, by preventing any methods, which can modify an instance, to appear in class.
This is no con for the other proposals, but pro for the best that I've ever seen :)
Go Smalltalk, go ! :)
/Klaus
So, the only real thing which can guarantee that given object remain unchanged during its lifetime is a class. An immutability bit is much worse thing comparing to this.
And second, its against the spirit of smalltalk. Smalltalk is one of the languages, where it tries to implement all things through behavior, not through using different VM/language magic intrinsics. It is not a problem, what VM having or not having an immutablity bit, its a problem, that current kernel classes and/or collections designed without looking at possible use cases where user wants to prevent object from being changed during its lifetime. So, maybe we should think how to refactor these classes instead of including one more magic thing?
On Wed, Jul 30, 2008 at 12:06 AM, Colin Putney cputney@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
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.
In GNU Smalltalk I don't have separate mutable/immutable strings, but storing a mutable string with #storeOn: will indeed produce something like "'foo' copy"; it was actually done to fix bugs.
There is a separate #storeLiteralOn: method used by the pretty-printer that omits the #copy message send, and prints a ##(...) compile-time expression if it is fed an arbitrary object.
Paolo
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
On Fri, Aug 1, 2008 at 5:13 PM, stephane ducasse stephane.ducasse@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)
:)
I like this idea of immutability.
Stef
Hello
I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?
Safety. One can no longer overwrite literals or methods (or anything else whose state you want to protect) accidentally.
Expressive power. One can use immutability as a write barrier in orthogonal persistence or distribution schemes (and other things) . One marks an object as immutable to indicate that it is persistent or distributed and its changes should be exported. The immutability scheme allows one to associate managers for specific objects that handle NoModificationErrors on a per-object basis. So if an object is immutable and has an appropriate manager that manager can temporarily enable immutablity for the object, allow the modification, communicate the modification (e.g. to a database or remote image) and then re-enable immutability. The framework allows an object to have multiple managers. (This is all standard Squeak and very similar to the code I wrote for VW. The VM code is also available from Cadence).
Then does it mean that we could get rid of symbols immutability does not imply unique identity.
No. As you point out Symbols are unique and so immutable strings don't replace them. But it is nice to have immutable Symbols. e.g. try to do this in your Squeak image: #class pvtAt: 1 put: 0 asCharacter Scary :)
Stef
Eliot Miranda wrote:
On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse <stephane.ducasse@free.fr mailto:stephane.ducasse@free.fr> wrote:
Hello I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?
Eliot, I read your answer and (like Colin probably) I didn't understand if you were speaking about immutable objects in Smalltalk, or of immutable strings (as in Java, where you have immutable java.lang.String objects and use java.lang.StringBuffer to obtain a restricted kind of mutability).
What family does newspeak fall in?
Paolo
On Wed, Jul 30, 2008 at 2:23 AM, Paolo Bonzini bonzini@gnu.org wrote:
Eliot Miranda wrote:
On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse < stephane.ducasse@free.fr mailto:stephane.ducasse@free.fr> wrote:
Hello
I'm reading newspeak spec and I like the idea of immutable strings. Now what does it really bring to us?
Eliot, I read your answer and (like Colin probably) I didn't understand if you were speaking about immutable objects in Smalltalk, or of immutable strings (as in Java, where you have immutable java.lang.String objects and use java.lang.StringBuffer to obtain a restricted kind of mutability).
So java strings are not really immutable but they don't provide a mutability API?
What family does newspeak fall in?
Its own :) Gilad will be pushing this area beyond what Smalltalk offers. For example one idea is for the class of literals to be determined at run-time depending on the instantiation of the module they're in. So 'foo' in a module Mx would, in an instantiation of Mx be an instance of ByteString if the the instantiation imported ByteString as the literal string class, and e.g. UTF8String in an instantiation that imported UTF8String as the literal string class. Obviously language semantics like this requires some additional behind-the-scenes machinery.
I think I'm correct in saying that currently Newspeak is intending to use Smalltalk-style immutable objects with per-object immutability enforced by inst var assignment checks and the mutating primitives. But this will be extended to a notion of deep immutability where a sub-graph of objects rooted at some immutable object will all be immutable. This is to support better actor-style concurrency. But don't take it form me. Post a question on Gilad's blog, or google gbracha.blogspot.com for Immutability.
Paolo
Eliot, I read your answer and (like Colin probably) I didn't understand if you were speaking about immutable objects in Smalltalk, or of immutable strings (as in Java, where you have immutable java.lang.String objects and use java.lang.StringBuffer to obtain a restricted kind of mutability).So java strings are not really immutable but they don't provide a mutability API?
No, java strings are immutable (because they are in a final, i.e. not inheritable class, and don't provide a mutability API).
A java.lang.StringBuffer object is substantially a mutable, growable String even though it is 99% of the time used the same way as a Smalltalk WriteStream. But the StringBuffer is not polymorphic with Strings: sooner or later however you'll have to convert the StringBuffer to a String to pass it to methods expecting a java.lang.String.
Paolo
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
Eliot Miranda -
Hans-Martin Mosner -
Igor Stasenko -
Janko Mivšek -
Jason Johnson -
Klaus D. Witzel -
Paolo Bonzini -
Philippe Marschall -
stephane ducasse -
tim Rowledge