odd gotcha in workspace code for squeak and pharo

A discussion in IRC prompted me to try several things.


In a nutshell, execute these two lines with two separate doits and you
get an error.
Select both lines and doit and you don't:

a := [^true].
a value.

I assume there is a valid reason for the difference in behavior, but it
DOES remind one that workspace behavior isn't always the same as method
behavior, even for something as simple as the above.

L.

On 3 March 2012 16:29, Lawson English <[hidden email]> wrote:
Indeed. Given there's a non-local return in the block, the statement
"return from the method context that invoked me" means something
rather different in the two ways you run this.

In the second case, you'll have an UndefinedObject>>DoIt context (call
it C1) running "a := [^true]". The ^ captures the home context - C1 -
so that when the block returns, it will return from C1. Since "a
value" then executes within C1's context, there's no problem.

But in the first case, C1 executes "a := [^ true]", finishes, and then
pops off the call stack. When you select "a value", it too executes
within an UndefinedObject>>DoIt context (call it C2). The block then
executes and "^ true" tries to return... from C1. Only C1's now
garbage.

In fact, within the debugger, go to the MethodContext>>cannotReturn:
context, and explore  "self home". You'll see that receiver = nil,
indicating that it's not connected to a call stack. Compare that
context with thisContext, and you'll see that thisContext receiver ~=
nil.

frank

Nice! So you mean block closures saves its context BlockContext and return(^) goes to just sender of the context.
If Frank was not right, We couldn't send at:ifAbsent: with second parameter [^self] which exits the sender ' s method would not work.

Oh, not sender of the context, but sender of sender of it. It is context of block, and sender is a method which made the block, and sender of the method is caller of the method.