Hi Ken -

Very interesting. Looks like an issue with OutOfScopeNotification. The 
problem appears to be that this code:

	"..." [ :a | a ].
	"..." a.

generates an OutOfScopeNotification that is being suppressed in 
workspaces (I'm not exactly sure why that is). This is of course is 
interesting because of the highly unusual situation of a temp shadowing 
a global instead of another temp / ivar. For example, this wouldn't compile:

   | a |
   [ :a | a ].

But stranglely, this does:

   [ :Object | Object ].

so your example code is roughly equivalent to running:

	b := [ :Object | Object ].
	c := b value: Object.

When you run this line by line it works 'as expected' and when you run 
it as a single doIt you get the result of c being a "[closure] in 
UndefinedObject>>DoIt" due to the OutOfScopeNotification.

Hope this explains the issue - as for how to fix it, I have no clue :-)

Cheers,
   - Andreas


On 5/16/2010 12:35 PM, Ken Causey wrote:
> Well, it's nothing new but this one has stumped me:
>
> http://bugs.squeak.org/view.php?id=7532
>
> Initially I (and Frank) thought the reporter was mistaken until we
> understood that the problem shows up when you execute the main code all
> in one do-it.  I've since modified the original report to make this
> clearer.
>
> So here it is:
>
> 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.
>
> Alternately, from a suggestion from jmckeon, if you specify a different
> symbol for the block argument:
>
> 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. (and d is nil)
>
> So what's up?
>
> Ken
>
>
>