Mantis - Squeak
Viewing Issue Advanced Details
7532 Tools minor always 05-15-10 11:41 02-06-11 23:47
unoduetre  
FrankShearar  
normal  
closed 4.1  
fixed  
none    
none trunk  
0007532: Problems with Blocks in Workspace
Following code in Workspace behaves unexpectedly:

a:=4. b:=[:a|a]. b value: a.
c class "BlockClosure"
c decompile "{[:t1 | t1]}"

Select the entire first line (3 statements) and do-it or print-it for all of them at once. If they are executed separately it works as expected.

Edit: Modified by KenCausey to be clearer. This negates the relevance of the first 2 notes below.

Notes
(0013771)
FrankShearar   
05-15-10 18:35   
What's unexpected? That you see a "t1" instead of "a"?
(0013772)
KenCausey   
05-15-10 19:02   
Indeed, I see nothing here unexpected. When you decompile from bytecode there is information to say that there are arguments and variables and how many, but not their names.
(0013774)
unoduetre   
05-16-10 07:55   
I'm really sorry. There is mistake in that code.
Please try this one:
a:=4.b:=[:a|a].c:=b value:a.
c class "BlockClosure".
c decompile "{[:t1|t1]}"
(0013775)
FrankShearar   
05-16-10 11:09   
There's something weird going on here, or I simply don't understand BlockClosures well enough. If you try this:

a := 4.
b := [ :n | n ]. "Note the new local var name."
c := b value: a.

then c contains 4 (the value of a), not a BlockClosure.
(0013776)
KenCausey   
05-16-10 19:08   
OK, now I see what you mean. If, in a workspace for example, you select the first 3 statements and execute them all at once, the result is a BlockClosure, not the value of a, 4, that you would expect. If you however execute each statement individually it works as expected. How to track down the cause I don't know.
(0013777)
KenCausey   
05-16-10 19:24   
Thanks to a suggestion from jmckeon on #squeak we have another data point at least, I'm not sure what it means. So once more here is the code with a problem (with all requisite whitespace).

a := 4.
b := [ :a | a ].
c := b value: a.

If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial detail). The result is that a is 4, b is a BlockClosure, and c is a BlockClosure not 4 as expected. Execute each statement separately and c is 4.

The new wrinkle is that

a := 4.
b := [ :d | d ].
c := b value: a.

when executed all at one time works as you would expect: a is 4, b is a BlockClosure, and c is 4.
(0013778)
nicolas cellier   
05-16-10 20:35   
Indeed, generated CompiledMethod is wrong:

29 <20> pushConstant: 4
30 <82 C1> popIntoLit: a
32 <8F 01 00 02> closureNumCopied: 0 numArgs: 1 bytes 36 to 37
36 <10> pushTemp: 0
37 <7D> blockReturn
38 <82 C2> popIntoLit: b
40 <42> pushLit: b
41 <10> pushTemp: 0
42 <CA> send: value:
43 <81 C3> storeIntoLit: c
45 <7C> returnTop

should be:

41 <41> pushLit: a

Since CompiledMethod has no temp, pushTemp: 0 can have unexpected results indeed
(0013779)
FrankShearar   
05-17-10 07:40   
http://source.squeak.org/trunk/Compiler-ar.141.mcz [^]