Very strange bug on Streams and probably compiler

> Execute the following piece of code:
>
>
> "-------------------------------------------------------------------"
> |stream stream2|
> stream := WriteStream with: 'a test '.
> stream reset.
> stream nextPutAll: 'to test'.
> self assert: [stream contents = 'to test'].
>
> "On the following line, you can remove 'copy'"
> "the problem is present without. It's here to prevent"
> " the streams from using the same collection"
> "because the compiler tries to avoid creating 2 identical"
> "strings"
> stream2 := WriteStream with: 'a test ' copy.
> stream2 nextPutAll: 'to test'.
>
> "This assert passes but this is abnormal"
> self assert: [stream2 contents = 'to testto test'].
>
> "This assert pass and this is abnormal too"
> "because the strings MUST be equal !!"
> self assert: [stream2 contents ~= 'a test to test']
> "-------------------------------------------------------------------"
>
>
>
> On my image, all the 3 tests pass. This is completely abnormal in  
> my opinion.

> From: Bert Freudenberg
> Sent: Wednesday, February 14, 2007 10:36 AM
>
>
> On Feb 14, 2007, at 16:18 , Damien Cassou wrote:
>
> > Execute the following piece of code:
> >
> >
> > "-------------------------------------------------------------------"
> > |stream stream2|
> > stream := WriteStream with: 'a test '.
> > stream reset.
> > stream nextPutAll: 'to test'.
> > self assert: [stream contents = 'to test'].
> >
> > "On the following line, you can remove 'copy'"
> > "the problem is present without. It's here to prevent"
> > " the streams from using the same collection"
> > "because the compiler tries to avoid creating 2 identical"
> > "strings"
> > stream2 := WriteStream with: 'a test ' copy.
> > stream2 nextPutAll: 'to test'.
> >
> > "This assert passes but this is abnormal"
> > self assert: [stream2 contents = 'to testto test'].
> >
> > "This assert pass and this is abnormal too"
> > "because the strings MUST be equal !!"
> > self assert: [stream2 contents ~= 'a test to test']
> > "-------------------------------------------------------------------"
> >
> >
> >
> > On my image, all the 3 tests pass. This is completely abnormal in
> > my opinion.
>
> It is normal.
>
> You are modifying the 'a test ' literal into 'to test'. This modified
> string gets copied in the second test.
>
> Lesson: never modify string literals.
>
> - Bert -
>
>
>

> Bert
>
>> It is normal.
>
> No this is not. You get used to it and accept it.
>>
>> You are modifying the 'a test ' literal into 'to test'. This  
>> modified string gets copied in the second test.
>>
>> Lesson: never modify string literals.
>
> It shows that the fact that the compiler optimizes the use of  
> certain literals such as boolean and number is good
> for immutable objects but is wrong for mutable object such as strings.
>
> Iin the semantics of Smalltalk nothing says that two strings with  
> the same representation in the same
> methods are pointing to the same object. I did not check in which  
> books but the difference between strings and symbols
> is really that two strings are pointing to two different objects,  
> while symbols are referring to the same objects (and are immutable).

> Bert
>
>> It is normal.
>
> No this is not. You get used to it and accept it.
>>
>> You are modifying the 'a test ' literal into 'to test'. This modified  
>> string gets copied in the second test.
>>
>> Lesson: never modify string literals.
>
> It shows that the fact that the compiler optimizes the use of certain  
> literals such as boolean and number is good
> for immutable objects but is wrong for mutable object such as strings.
>
> Iin the semantics of Smalltalk nothing says that two strings with the  
> same representation in the same
> methods are pointing to the same object. I did not check in which books  
> but the difference between strings and symbols
> is really that two strings are pointing to two different objects, while  
> symbols are referring to the same objects (and are immutable).
>
> Stef
>
>

> On Feb 14, 2007, at 4:36 PM, Bert Freudenberg wrote:
>
>
>> It is normal.
>
>
> This is normal for you because you know how the compiler works. But
> do you think the compiler works normally? Is it normal that a
> compiler considers two equal strings as identical? I would agree with
> symbols because symbols are immutable. I think this is a first bug, a
> bug in the compiler.
>
> In my opinion, there is another bug. When the collection of a stream
> becomes full, its is replaced by another bigger collection. So,
> first, the stream uses the collection you passed to the constructor,
> then, at a given time, this collection is replaced by a new one. I
> don't think it's a normal behavior.

> In my opinion, the collection
> must always be the one you gave at the beginning OR it must always be
> a copy. I prefer the second solution.
>
> So, what should be done ? I can write tests for the compiler and
> tests for streams to show the behavior. This tests will fail because
> they show a non corrected bug.
>
>
>> Lesson: never modify string literals.
>
> Lesson: Use a correct compiler :-)
>

>> As Bert wrote: it's normal :)
>
> I agree, looks completely normal to me.
>
>> [Okay okay other languages have immutable string, but this is  
>> Smalltalk.]
>
> If we had an immutability bit, that the compiler would set for objects
> in the literal array (and with what we could do a lot of other cool
> stuff), then people would not run into such problems.

> On Feb 14, 2007, at 5:48 PM, Klaus D. Witzel wrote:
>> Hi Damien,
>> on Wed, 14 Feb 2007 17:19:13 +0100, you wrote:
>>> On Feb 14, 2007, at 4:36 PM, Bert Freudenberg wrote:
>>>
>>>
>>>> It is normal.
>>>
>>>
>>> This is normal for you because you know how the compiler works. But
>>> do you think the compiler works normally? Is it normal that a
>>> compiler considers two equal strings as identical? I would agree with
>>> symbols because symbols are immutable. I think this is a first bug, a
>>> bug in the compiler.
>>>
>>> In my opinion, there is another bug. When the collection of a stream
>>> becomes full, its is replaced by another bigger collection. So,
>>> first, the stream uses the collection you passed to the constructor,
>>> then, at a given time, this collection is replaced by a new one. I
>>> don't think it's a normal behavior.
>>
>> Whatever the stream does with the collection, it is encapsulated.
>> Imagine the stream always uses a highly optimized species for its
>> internal job (or a file on your harddisk!). You should not depend
>> any code on the internals of (in this case) stream.
>
>
> I really don't want to depend on the implementation. And in my
> opinion, this is not encapsulated because this is MY String, not a
> String created internally.

>
> The same situation is, for example, with Associations. In order to  
> prevent mutation, someone invented ReadOnlyVariableBinding.
>
> Literals have nothing much to do with compiler optimization, see  
> senders of #encodeLiteral:, just with determining the correct  
> bytecode for pushing them onto the stack.
>
> But of course the compiler could emit code for always copying  
> string literals, if you can afford the performance penalty.
>
> As Bert wrote: it's normal :)
>
> [Okay okay other languages have immutable string, but this is  
> Smalltalk.]
>
> /Klaus
>
> On Wed, 14 Feb 2007 16:56:56 +0100, stephane ducasse wrote:
>
>> Bert
>>
>>> It is normal.
>>
>> No this is not. You get used to it and accept it.
>>>
>>> You are modifying the 'a test ' literal into 'to test'. This  
>>> modified string gets copied in the second test.
>>>
>>> Lesson: never modify string literals.
>>
>> It shows that the fact that the compiler optimizes the use of  
>> certain literals such as boolean and number is good
>> for immutable objects but is wrong for mutable object such as  
>> strings.
>>
>> Iin the semantics of Smalltalk nothing says that two strings with  
>> the same representation in the same
>> methods are pointing to the same object. I did not check in which  
>> books but the difference between strings and symbols
>> is really that two strings are pointing to two different objects,  
>> while symbols are referring to the same objects (and are immutable).
>>
>> Stef
>>
>>
>
>
>

>>> It is normal.
>>
>> No this is not. You get used to it and accept it.
>>>
>>> You are modifying the 'a test ' literal into 'to test'. This  
>>> modified string gets copied in the second test.
>>>
>>> Lesson: never modify string literals.
>>
>> It shows that the fact that the compiler optimizes the use of  
>> certain literals such as boolean and number is good
>> for immutable objects but is wrong for mutable object such as  
>> strings.
>>
>> Iin the semantics of Smalltalk nothing says that two strings with  
>> the same representation in the same
>> methods are pointing to the same object. I did not check in which  
>> books but the difference between strings and symbols
>> is really that two strings are pointing to two different objects,  
>> while symbols are referring to the same objects (and are immutable).
>
> The sharing is not the primary problem, the mutability is.
>
> - Bert -
>
>
>
>

>> > Lesson: never modify string literals.
>
> Ohh god, how much I wish to have immutability on a per object bases.
>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>

> The same situation is, for example, with Associations. In order to  
> prevent mutation, someone invented ReadOnlyVariableBinding.
>
> Literals have nothing much to do with compiler optimization, see  
> senders of #encodeLiteral:, just with determining the correct  
> bytecode for pushing them onto the stack.
>
> But of course the compiler could emit code for always copying  
> string literals, if you can afford the performance penalty.
>
> As Bert wrote: it's normal :)
>
> [Okay okay other languages have immutable string, but this is  
> Smalltalk.]