On Sat, Dec 19, 2009 at 4:12 AM, Andreas Raab andreas.raab@gmx.de wrote:

Eliot Miranda wrote:

...

Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be

BlockClosure methods for accessing sender ^self home sender

A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method.

How about instead of faking out BlockClosure>>sender we fix MessageTally along the lines of:

MessageTally>>tallySendsTo:inBlock:showTree:

prev := aBlock asContextWithSender: thisContext.

This should work just as well if I understand the intent of the change correctly.

That's right. In the Teleplace codebase we simply use asContext:

tallySendsTo: receiver inBlock: aBlock showTree: treeOption ... thisContext sender runSimulated: (prev := aBlock asContext) contextAtEachStep: [:current | ...

Cheers,

• Andreas

On Wed, Dec 23, 2009 at 12:27 PM, Igor Stasenko siguctua@gmail.com wrote:

2009/12/19 Eliot Miranda eliot.miranda@gmail.com:

...

Hi David, Interesting! To my mind that definition is incorrect. I would

expect

...

the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block

you

...

might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender

refers

...

to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be MethodContext methods for accessing caller ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] sender ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] BlockClosure methods for accessing sender ^outerContext sender and either BlockClosure methods for accessing caller "Since a BlockClosure is by definition not an activation it does not have

a

...

caller. It has a sender because it is always created within the context of a method." ^nil or BlockClosure methods for accessing caller ^self error: 'this is an inactive block and so has no caller'

I believe the pre-closure definitions are ContextPart methods for accessing sender ^sender BlockContext methods for accessing caller ^sender which to my mind is missing BlockContext methods for accessing sender ^home sender What do people think the right definitions should be?

i think the intent of this fix was to match the:

|x y | x := thisContext sender. [ y := thisContext sender ] value. x == y

NI don't think so. Within a block thisContext is not a BlockClosure but a MethodContext (note not a BlockContext). The fix was for BlockClosure not ContextPart et al. Again "[] home sender" is the right approach (see below).

(*) That it is a MethodContext is a historical accident. My closure implementation discards BlockContext. Some time we should merge ContextPart and MethodContext into a single class Context.

Since thisContext variable value depending on scope, where it used.

The really interesting question to answer is:

either we threat thisContext as implicitly declared in method's scope only:

someMethod | thisContext |

[ [ [ [ x := thisContext ] ] ] ]

or threat as implicitly (re)declared at each level of scoping:

someMethod | thisContext |

[| thisContext | [| thisContext | [| thisContext | [| thisContext | x := thisContext ] ] ] ]

Not so interesting :) It has to be the latter because you have to be able to name the current context. If you need to mention the former you write "thisContext home". And so "aClosureOrContext home sender" will answer the enclosing method activation's sending context for both blocks and contexts.

...

On Fri, Dec 18, 2009 at 8:36 PM, commits@source.squeak.org wrote:

...

David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.331.mcz

==================== Summary ====================

Name: Kernel-dtl.331 Author: dtl Time: 18 December 2009, 11:32:44 am UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e Ancestors: Kernel-bs.330

Add BlockClosure>>sender required for MessageTally class>>tallySends:

Harvested from Pharo (nice 4/14/2009 19:09).

=============== Diff against Kernel-bs.330 ===============

Item was added:

• ----- Method: BlockClosure>>sender (in category 'debugger access')

---

...

...

• sender

•   "Answer the context that sent the message that created the
  

receiver."

•   ^outerContext sender!
  
  
  

-- Best regards, Igor Stasenko AKA sig.