[Pharo-project] strange == behavior
Hi guys, Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. If in an workspace we try to evaluate: a := Association new. a key: 3. a value: a. a == a value. the first time we get "true", the second we get an infinite loop... A simple workaround is to declare "a": |a| a := Association new. a key: 3. a value: a. a == a value. My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally. By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
by the way, we have the same thing in 1.0, 1.1, 1.3. On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com
wrote:
Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Same behavior in Squeak 4.2 btw  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
________________________________ From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...Â
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."Â
Cheers,-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
It seems that this issue can be fixed by modifying the = method in Association. Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ] Cheers... On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:
Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ *From:* Ciprian Teodorov <ciprian.teodorov@gmail.com> *To:* Pharo-project@lists.gforge.inria.fr *Sent:* Saturday, December 8, 2012 11:11:44 AM *Subject:* Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < ciprian.teodorov@gmail.com> wrote:
Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Can you add a issue at http://code.google.com/p/pharo/issues/list ? On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
I reported. I am doing the slice. 2012/12/9 Marcus Denker <marcus.denker@inria.fr>
Can you add a issue at http://code.google.com/p/pharo/issues/list ? On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:
Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
------------------------------ *From:* Ciprian Teodorov <ciprian.teodorov@gmail.com> *To:* Pharo-project@lists.gforge.inria.fr *Sent:* Saturday, December 8, 2012 11:11:44 AM *Subject:* Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < ciprian.teodorov@gmail.com> wrote:
Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Hi guys what is the impact on method =? Any ideas? Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
The sole impact I can't think of is (#x -> Float nan) = (#x -> Float nan) Nicolas 2012/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
I am not pro, see my comments in the issue tracker. For example, | a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)). would still loop. Loops like that cannot be prevented locally. See my other mail about prevent stack overflow. On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values. But self-referencing data structures is and will be a problem. And there is no easy solution: a := Array new: 1. a at:1 put: a. a = a On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On Dec 9, 2012, at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But it's not very clear why? Why should (1 -> 2) = (1 -> 4) be true? They are not the same! If you want to compare keys, you can easily write (1 -> 2) key = (1 -> 4) key and the people reading the code will directly understand what your intention is. Marcus
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On 9 December 2012 19:34, Marcus Denker <marcus.denker@inria.fr> wrote:
On Dec 9, 2012, at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But it's not very clear why? Why should
(1 -> 2) = (1 -> 4)
be true? They are not the same!
simply for the reason that associations are part of dictionaries. if you need to use associations outside of dicts, why not just using simple arrays? #(1 2) = #( 1 4) or ask yourself, why then we need a distinct class for associations, if its behavior is same as for collection of 2 elements? Lets then just rewrite Dictionary to use array first / array second instead of association key / value.
If you want to compare keys, you can easily write
(1 -> 2) key = (1 -> 4) key
and the people reading the code will directly understand what your intention is.
if we follow this, then all comparison methods in system should be implemented to always compare all fields for equality, without exception. Otherwise you risking to confuse people a lot ! :)
Marcus
-- Best regards, Igor Stasenko.
Hi guys, I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation... Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know. On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
As for the = method in Association (besides perverted side effects) I think that my code is at least logical. If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with = BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key). On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com
wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey). Nicolas 2012/12/9 Ciprian Teodorov <ciprian.teodorov@gmail.com>:
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote:
Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey).
BTW in that case should not be LookupKey be called IdentityLookupKey
Nicolas
2012/12/9 Ciprian Teodorov <ciprian.teodorov@gmail.com>:
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
No, it's just a fast test, because if objects are == they also are = (except Float nan). However, if they are ~~ they still can be =. If you look at SequenceableCollection>>= otherCollection "Answer true if the receiver is equivalent to the otherCollection. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the otherCollection." self == otherCollection ifTrue: [^ true]. self species == otherCollection species ifFalse: [^ false]. ^ self hasEqualElements: otherCollection We could do the same with Association... LookupKey>>= aLookupKey self == aLookupKey ifTrue: [^ true]. self species = aLookupKey species ifTrue: [^key = aLookupKey key] ifFalse: [^false] Note that this has side effect for the sole object I know not equal to itself: | a | a := {Float nan}. a = a. "is true" a = {Float nan }. "is false" | a | a := #x -> Float nan. a = a. "is currently false but would be true after LookupKey change" a = #x -> Float nan. "false even after LookupKey change, true after Ciprian fix, but should it?" Nicolas 2012/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote:
Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey).
BTW in that case should not be LookupKey be called IdentityLookupKey
Nicolas
2012/12/9 Ciprian Teodorov <ciprian.teodorov@gmail.com>:
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Ah, my mistake, modifying LookupKey does nothing to Association we should move the == test in Associaiton itself... 2012/12/9 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
No, it's just a fast test, because if objects are == they also are = (except Float nan). However, if they are ~~ they still can be =.
If you look at SequenceableCollection>>= otherCollection "Answer true if the receiver is equivalent to the otherCollection. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the otherCollection."
self == otherCollection ifTrue: [^ true]. self species == otherCollection species ifFalse: [^ false]. ^ self hasEqualElements: otherCollection
We could do the same with Association... LookupKey>>= aLookupKey
self == aLookupKey ifTrue: [^ true]. self species = aLookupKey species ifTrue: [^key = aLookupKey key] ifFalse: [^false]
Note that this has side effect for the sole object I know not equal to itself:
| a | a := {Float nan}. a = a. "is true" a = {Float nan }. "is false"
| a | a := #x -> Float nan. a = a. "is currently false but would be true after LookupKey change" a = #x -> Float nan. "false even after LookupKey change, true after Ciprian fix, but should it?"
Nicolas
2012/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote:
Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey).
BTW in that case should not be LookupKey be called IdentityLookupKey
Nicolas
2012/12/9 Ciprian Teodorov <ciprian.teodorov@gmail.com>:
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
What downsides would be to doing... Float>>nan ^ NaN copy. Nicolas Cellier wrote:
No, it's just a fast test, because if objects are == they also are = (except Float nan). However, if they are ~~ they still can be =.
If you look at SequenceableCollection>>= otherCollection "Answer true if the receiver is equivalent to the otherCollection. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the otherCollection."
self == otherCollection ifTrue: [^ true]. self species == otherCollection species ifFalse: [^ false]. ^ self hasEqualElements: otherCollection
We could do the same with Association... LookupKey>>= aLookupKey
self == aLookupKey ifTrue: [^ true]. self species = aLookupKey species ifTrue: [^key = aLookupKey key] ifFalse: [^false]
Note that this has side effect for the sole object I know not equal to itself:
| a | a := {Float nan}. a = a. "is true" a = {Float nan }. "is false"
| a | a := #x -> Float nan. a = a. "is currently false but would be true after LookupKey change" a = #x -> Float nan. "false even after LookupKey change, true after Ciprian fix, but should it?"
Nicolas
2012/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote:
Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey).
BTW in that case should not be LookupKey be called IdentityLookupKey
Nicolas
2012/12/9 Ciprian Teodorov <ciprian.teodorov@gmail.com>:
As for the = method in Association (besides perverted side effects) I think that my code is at least logical.
If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with =
BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key).
On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation...
Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know.
On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values.
But self-referencing data structures is and will be a problem. And there is no easy solution:
a := Array new: 1. a at:1 put: a.
a = a
On 9 December 2012 17:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not pro, see my comments in the issue tracker.
For example,
| a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)).
would still loop.
Loops like that cannot be prevented locally.
See my other mail about prevent stack overflow.
On 09 Dec 2012, at 16:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
what is the impact on method =? Any ideas?
Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote:
It seems that this issue can be fixed by modifying the = method in Association.
Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ]
Cheers...
On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean@yahoo.com> wrote: Same behavior in Squeak 4.2 btw
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Ciprian Teodorov <ciprian.teodorov@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Saturday, December 8, 2012 11:11:44 AM Subject: Re: [Pharo-project] strange == behavior
by the way, we have the same thing in 1.0, 1.1, 1.3.
On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote: Hi guys,
Playing with some recursive data-structure I have found some strange piece of behavior in Pharo.
If in an workspace we try to evaluate:
a := Association new. a key: 3. a value: a. a == a value.
the first time we get "true", the second we get an infinite loop...
A simple workaround is to declare "a":
|a| a := Association new. a key: 3. a value: a. a == a value.
My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally.
By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
participants (9)
-
Ben Coman -
Benoit St-Jean -
Ciprian Teodorov -
Clément Bera -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe