Folks,

I use Block temps a lot in throwaway calculations, because I can put the 
temp declaration near the scope where it's used.  So here I was, debugging 
a longish expression in a Workspace, and all my variables had the wrong 
values.  That wouldn't be too uncommon, except that it was nigh impossible 
in this case.  The Debugger had simply rearranged them a bit.  Maybe my 
code was boring.

I have pondered the problem for a short while, and can't come up with an 
easy fix, so I thought I'd at least post a reminder, so that others don't 
fall into the same trap.

If you're curious, feel free to try out

#(1) do:
	[:one || two three |
	two _ 2.
	three _ 3.
	self halt: 'Press Debug']

and in the Debugger, examine the temps of the BlockContext. :-o

(What we do in Parser>>blockExpression is to reserve method temps *after* 
parsing and allocating a slot for the block argument.  So, in the bytecode, 
"one" gets code 16, "two" gets code 17, and "three" gets code 18.  Browse 
implementors of #DoIt and show bytecodes to verify.  However, the 
MethodNode's Encoder sees the #tempNodes as "two"=16, "three"=17 and "one"= 
18.  Thus, evaluating "two" in the Debugger will give you 1, etc.
Yes I know, we all were being told that we were cheating when we got block 
temps.  And we can't cheat more by simply parsing the block's #argumentName 
s, allocating block temps first, and then going back and allocating the 
block argument slots, because we might have nested block temps ahead.)

Go, BlockClosures, go!

Cheers,
Helge