modified method temp references in closures: possible bug?
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): expected (by my feeble mind): 1 2 actual: 2 2 | methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. Should I open a bug report? Cheers, Max
On 2 August 2013 15:08, Max Leske <maxleske@gmail.com> wrote:
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
err.. i see dict add: but where dict was declared?
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
-- Best regards, Igor Stasenko.
This is not a bug. Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2. If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] 2013/8/2 Max Leske <maxleske@gmail.com>
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
Sorry, yes, "dict" should be "collection". On 02.08.2013, at 15:16, Clément Béra <bera.clement@gmail.com> wrote:
This is not a bug.
Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope.
Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. I totally agree with you that the variables belong to the block and should be declared there.
Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2.
If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block.
collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ]
2013/8/2 Max Leske <maxleske@gmail.com>
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
On 2 August 2013 15:27, Max Leske <maxleske@gmail.com> wrote:
Sorry, yes, "dict" should be "collection".
On 02.08.2013, at 15:16, Clément Béra <bera.clement@gmail.com> wrote:
This is not a bug.
yes, the expression: [ methodScope ] does not capturing the current value of methodScope variable. means that closure, when evaluated will always return the value methodScope at the moment of evaluation. Closures do not capturing values of free variables, because then it will mean different semantic than rest of code (in method's body).
Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope.
Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one.
I totally agree with you that the variables belong to the block and should be declared there.
Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2.
If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block.
collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ]
2013/8/2 Max Leske <maxleske@gmail.com>
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
-- Best regards, Igor Stasenko.
On 02.08.2013, at 15:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 August 2013 15:27, Max Leske <maxleske@gmail.com> wrote:
Sorry, yes, "dict" should be "collection".
On 02.08.2013, at 15:16, Clément Béra <bera.clement@gmail.com> wrote:
This is not a bug.
yes, the expression:
[ methodScope ]
does not capturing the current value of methodScope variable.
means that closure, when evaluated will always return the value methodScope at the moment of evaluation.
Closures do not capturing values of free variables, because then it will mean different semantic than rest of code (in method's body).
Ok, thanks.
Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope.
Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one.
I totally agree with you that the variables belong to the block and should be declared there.
Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2.
If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block.
collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ]
2013/8/2 Max Leske <maxleske@gmail.com>
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
-- Best regards, Igor Stasenko.
In fact we say that closure capture variables but they capture "location" or access to variables. I will reread what I wrote I gave some examples in the forth coming book Deep into Pharo :) http://rmod.lille.inria.fr/pbe2/ On Aug 2, 2013, at 3:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 August 2013 15:27, Max Leske <maxleske@gmail.com> wrote:
Sorry, yes, "dict" should be "collection".
On 02.08.2013, at 15:16, Clément Béra <bera.clement@gmail.com> wrote:
This is not a bug.
yes, the expression:
[ methodScope ]
does not capturing the current value of methodScope variable.
means that closure, when evaluated will always return the value methodScope at the moment of evaluation.
Closures do not capturing values of free variables, because then it will mean different semantic than rest of code (in method's body).
Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope.
Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one.
I totally agree with you that the variables belong to the block and should be declared there.
Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2.
If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block.
collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ]
2013/8/2 Max Leske <maxleske@gmail.com>
I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog):
expected (by my feeble mind): 1 2
actual: 2 2
| methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ].
collection do: [ :block | Transcript show: block value; cr ]
I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors.
Should I open a bug report?
Cheers, Max
-- Best regards, Igor Stasenko.
participants (4)
-
Clément Béra -
Igor Stasenko -
Max Leske -
Stéphane Ducasse