Smalltalk (Pharo) and String equality

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Smalltalk (Pharo) and String equality

laurent laffont
Hi,

Something strange to me: 

'2' = '2'. -> true  (OK)
(2 asString) = (2 asString). -> true  (OK)

(2 asString) == (2 asString). -> false  (OK)
'2' == '2'. -> true  ?????

Laurent

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Stéphane Ducasse
this is because of an optimisation

string  inside the same methods are reused.

if you want to show that string are different than symbol use two methods
returning the same strings



On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:

> Hi,
>
> Something strange to me:
>
> '2' = '2'. -> true  (OK)
> (2 asString) = (2 asString). -> true  (OK)
>
> (2 asString) == (2 asString). -> false  (OK)
> '2' == '2'. -> true  ?????
>
> Laurent
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Mariano Martinez Peck
I think the same happens in Java. It is a VM optimization.

Compare "Something" == "Something"  true

On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <[hidden email]> wrote:
this is because of an optimisation

string  inside the same methods are reused.

if you want to show that string are different than symbol use two methods
returning the same strings



On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:

> Hi,
>
> Something strange to me:
>
> '2' = '2'. -> true  (OK)
> (2 asString) = (2 asString). -> true  (OK)
>
> (2 asString) == (2 asString). -> false  (OK)
> '2' == '2'. -> true  ?????
>
> Laurent
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

laurent laffont
In reply to this post by Stéphane Ducasse
On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <[hidden email]> wrote:
this is because of an optimisation

string  inside the same methods are reused.

OK

 
if you want to show that string are different than symbol use two methods
returning the same strings

Hey !! Telepathy power ? You've used the force ? You master the Wakfu ?

Laurent 
 



On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:

> Hi,
>
> Something strange to me:
>
> '2' = '2'. -> true  (OK)
> (2 asString) = (2 asString). -> true  (OK)
>
> (2 asString) == (2 asString). -> false  (OK)
> '2' == '2'. -> true  ?????
>
> Laurent
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Marcus Denker-4
In reply to this post by laurent laffont

On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:

> Hi,
>
> Something strange to me:
>
> '2' = '2'. -> true  (OK)
> (2 asString) = (2 asString). -> true  (OK)
>
> (2 asString) == (2 asString). -> false  (OK)
> '2' == '2'. -> true  ?????
>

Yes, the same string in the same method points to the same entry in the literalframe.

Which explains why this method works:

strange
        'hello world' isString ifTrue: ['hello world' become: {0}].
        'hello world' at: 1 put: ('hello world' at:1) + 1 .
        ^'hello world'  at: 1.

Put this method in Object, than print multiple times:

        Object new strange

:-)

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Nicolas Cellier
One of my first bug in st80 was

strange
    ^('foo' writeStream) nextPutAll: '-bar'; contents.

At that time, writing pastEnd did use become:

But if you really have time to pick an immutability bit in Newspeak,
we don't have to care anymore.

Nicolas

2010/1/17 Marcus Denker <[hidden email]>:

>
> On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
>
>> Hi,
>>
>> Something strange to me:
>>
>> '2' = '2'. -> true  (OK)
>> (2 asString) = (2 asString). -> true  (OK)
>>
>> (2 asString) == (2 asString). -> false  (OK)
>> '2' == '2'. -> true  ?????
>>
>
> Yes, the same string in the same method points to the same entry in the literalframe.
>
> Which explains why this method works:
>
> strange
>        'hello world' isString ifTrue: ['hello world' become: {0}].
>        'hello world' at: 1 put: ('hello world' at:1) + 1 .
>        ^'hello world'  at: 1.
>
> Put this method in Object, than print multiple times:
>
>        Object new strange
>
> :-)
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Marcus Denker-4

On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote:
> But if you really have time to pick an immutability bit in Newspeak,
> we don't have to care anymore.
>
Hmm... the code below should even work with immutable strings. I *never* touch
the string! I do not even manipulate the literal array via #at:put:...

I just become the pointer to an Array generated with {}, which would not
be immutable...

So I wonder if the immutability solved the problem. (immutable literals
do solve many other bugs when the object itself gets modified...).

>> strange
>>        'hello world' isString ifTrue: ['hello world' become: {0}].
>>        'hello world' at: 1 put: ('hello world' at:1) + 1 .
>>        ^'hello world'  at: 1.



        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Nicolas Cellier
2010/1/17 Marcus Denker <[hidden email]>:

>
> On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote:
>> But if you really have time to pick an immutability bit in Newspeak,
>> we don't have to care anymore.
>>
> Hmm... the code below should even work with immutable strings. I *never* touch
> the string! I do not even manipulate the literal array via #at:put:...
>
> I just become the pointer to an Array generated with {}, which would not
> be immutable...
>
> So I wonder if the immutability solved the problem. (immutable literals
> do solve many other bugs when the object itself gets modified...).
>

I extrapolated a bit...
In VW, this leads to an immutability error:

('abc' become: #(1 2 3)) at: 1

Nicolas

>>> strange
>>>        'hello world' isString ifTrue: ['hello world' become: {0}].
>>>        'hello world' at: 1 put: ('hello world' at:1) + 1 .
>>>        ^'hello world'  at: 1.
>
>
>
>        Marcus
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Levente Uzonyi-2
In reply to this post by Nicolas Cellier
On Sun, 17 Jan 2010, Nicolas Cellier wrote:

> One of my first bug in st80 was
>
> strange
>    ^('foo' writeStream) nextPutAll: '-bar'; contents.
>
> At that time, writing pastEnd did use become:
>
> But if you really have time to pick an immutability bit in Newspeak,
> we don't have to care anymore.

If I had a free bit in the object header, I'd use it for extending the
identity hash instead of useless things like immutability. IMO it was a
mistake to add immutability for literals in other smalltalks only to avoid
possible errors generated by the broken stream/collection semantics.


Levente

>
> Nicolas
>
> 2010/1/17 Marcus Denker <[hidden email]>:
>>
>> On Jan 17, 2010, at 6:30 PM, laurent laffont wrote:
>>
>>> Hi,
>>>
>>> Something strange to me:
>>>
>>> '2' = '2'. -> true  (OK)
>>> (2 asString) = (2 asString). -> true  (OK)
>>>
>>> (2 asString) == (2 asString). -> false  (OK)
>>> '2' == '2'. -> true  ?????
>>>
>>
>> Yes, the same string in the same method points to the same entry in the literalframe.
>>
>> Which explains why this method works:
>>
>> strange
>>        'hello world' isString ifTrue: ['hello world' become: {0}].
>>        'hello world' at: 1 put: ('hello world' at:1) + 1 .
>>        ^'hello world'  at: 1.
>>
>> Put this method in Object, than print multiple times:
>>
>>        Object new strange
>>
>> :-)
>>
>> --
>> Marcus Denker  -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Martin McClure-2
Levente Uzonyi wrote:

> On Sun, 17 Jan 2010, Nicolas Cellier wrote:
>
>> One of my first bug in st80 was
>>
>> strange
>>    ^('foo' writeStream) nextPutAll: '-bar'; contents.
>>
>> At that time, writing pastEnd did use become:
>>
>> But if you really have time to pick an immutability bit in Newspeak,
>> we don't have to care anymore.
>
> If I had a free bit in the object header, I'd use it for extending the
> identity hash instead of useless things like immutability. IMO it was a
> mistake to add immutability for literals in other smalltalks only to
> avoid possible errors generated by the broken stream/collection semantics.

Literal immutability and other object immutability is only one use of
the so-called "immutability" bit. In reality, this bit is a "track
modifications" bit, and I find the other uses much more valuable.

Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Levente Uzonyi-2
On Sun, 17 Jan 2010, Martin McClure wrote:

> Levente Uzonyi wrote:
>> On Sun, 17 Jan 2010, Nicolas Cellier wrote:
>>
>>> One of my first bug in st80 was
>>>
>>> strange
>>>    ^('foo' writeStream) nextPutAll: '-bar'; contents.
>>>
>>> At that time, writing pastEnd did use become:
>>>
>>> But if you really have time to pick an immutability bit in Newspeak,
>>> we don't have to care anymore.
>>
>> If I had a free bit in the object header, I'd use it for extending the
>> identity hash instead of useless things like immutability. IMO it was a
>> mistake to add immutability for literals in other smalltalks only to
>> avoid possible errors generated by the broken stream/collection semantics.
>
> Literal immutability and other object immutability is only one use of
> the so-called "immutability" bit. In reality, this bit is a "track

http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180

> modifications" bit, and I find the other uses much more valuable.

I wonder how that works.


Levente

>
> Regards,
>
> -Martin
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Nicolas Cellier
2010/1/17 Levente Uzonyi <[hidden email]>:

> On Sun, 17 Jan 2010, Martin McClure wrote:
>
>> Levente Uzonyi wrote:
>>> On Sun, 17 Jan 2010, Nicolas Cellier wrote:
>>>
>>>> One of my first bug in st80 was
>>>>
>>>> strange
>>>>    ^('foo' writeStream) nextPutAll: '-bar'; contents.
>>>>
>>>> At that time, writing pastEnd did use become:
>>>>
>>>> But if you really have time to pick an immutability bit in Newspeak,
>>>> we don't have to care anymore.
>>>
>>> If I had a free bit in the object header, I'd use it for extending the
>>> identity hash instead of useless things like immutability. IMO it was a
>>> mistake to add immutability for literals in other smalltalks only to
>>> avoid possible errors generated by the broken stream/collection semantics.
>>
>> Literal immutability and other object immutability is only one use of
>> the so-called "immutability" bit. In reality, this bit is a "track
>
> http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180
>

Sure, object databases are more interesting applications, since you
generally make such mistake only once.
As a beginner, I put a halt in the method once identified as the
source of the problem, and did not understand my mistake at first shot
since it started working again (being recompiled). The good thing is
that it helped me learning some Smalltalk superpowers faster :).

Nicolas

>> modifications" bit, and I find the other uses much more valuable.
>
> I wonder how that works.
>
>
> Levente
>
>>
>> Regards,
>>
>> -Martin
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk (Pharo) and String equality

Martin McClure-2
Nicolas Cellier wrote:
>
> Sure, object databases are more interesting applications, since you
> generally make such mistake only once.
> As a beginner, I put a halt in the method once identified as the
> source of the problem, and did not understand my mistake at first shot
> since it started working again (being recompiled). The good thing is
> that it helped me learning some Smalltalk superpowers faster :).

Yes, I love the way that you can come to understand Smalltalk through
debugging it.

Modification tracking is good for more than just object databases.
Object-relational mapping, distributed object systems, debugging,
analysis, probably more -- all benefit from being able to tell when an
object is modified, and all care at a different level of abstraction
from the application itself, so it's better if you don't have to put the
modification-detection code in the application code.

Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project