[squeak-dev] About String vs Symbols

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

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 <[hidden email] <mailto:[hidden email]>> 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

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; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Soft rock

Philippe Marschall schrieb:

> 2008/7/29 Eliot Miranda <[hidden email]>:
>
>> On Tue, Jul 29, 2008 at 1:03 PM, Janko Mivšek <[hidden email]>
>> 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

Eliot Miranda wrote:

On Tue, Jul 29, 2008 at 9:21 AM, stephane ducasse <[hidden email] <mailto:[hidden email]>> 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 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 <[hidden email]>:

>
> 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.