On Wed, Apr 21, 2010 at 4:34 PM, Hern�n Morales Durand <hernan.morales@gmail.com> wrote:
2010/4/21 Lukas Renggli <renggli@gmail.com>:
>> thisContext is a special object for representing an activation in a
>> stack frame in a stack-based VM.
>
> Actually "thisContext" represents *the current* activation/stack-frame.
>
> � �foo: anObject
> � � � � ^ thisContext at: 1
>
> is the same as
>
> � �foo: anObject
> � � � � ^ anObject
>

Of course, "this" refers to "the current" in common language usage.

>> There are two kinds of contexts:
>> Method Contexts and Block Contexts.
>
> Actually in Pharo images there are only instances of MethodContext.
> Though you can ask the context if it comes from a block by sending the
> message #isExecutingBlock.
>

Actually in Pharo there is a BlockContext class, which is not
instantiated anymore after the introduction of the closure compiler?

Right.
�
In other Smalltalks aBlockContext is the resulting context of a block
activation during its evaluation and is activated by sending
#value,.this fills thisContext with the execution information inside
the block.

and it is now with the closure compiler. �Or rather a new context is created when a BlockClosure is sent the value message. �The context is an instance of methodContext though.
�
In Squeak (or the old compiler) block contexts were created using
#blockCopy:, now I see #closureNumCopied:numArgs:. Does this means
BlockContext could be completely removed and replaced with
MethodContext semantics? I've removed the BlockContext class and used
Pharo a little bit with no problems, maybe some Decompiler issues in
the Debugger...

Yes. �But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block). �If nil, ^-returns return to the context's sender. �If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var. �So we no longer need BlockContext.

This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class. �Possibly the name should be ExecutionContext or MethodOrBlockContext or? �Suggestions?


Now, test yourself before evaluating :) what should be the result of
this expression?

[: arg | arg perform: #isExecutingBlock ] value: thisContext

It depends on whether the expression is executed at method level or at block level. �As a test this should be:

testIsExecutingBlock
�� �self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false.
�� �[self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value

Can somebody justify the result?

isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not. �Remember that

�� �[:arg| arg == thisContext] value: thisContext

is false. �thisContext is rebound within every actual method or block scope.

HTH

Eliot


>> Context creation is optimized in the VM in most Smalltalks, so it's
>> only really created as an object in the environment (reified) when
>> it's specifically needed through "thisContext".
>
> In Pharo contexts are not reified like that. Stack-frames are actual
> objects at all times. However, for speed reasons, their creation and
> garbage-collection is optimized by the VM. Stack frames get
> automatically recycled if nobody refers to them.
>

I think is what I said :)

But its not a property of Pharo. �It is a property of the VM. �In Cog contexts are not actual objects all the time, only when needed. �And Cog runs Pharo images just as it runs Squeak images. �So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM".


>> There are several applications related with computational reflection
>> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
>> of the current context.
>
> Also: exception handling, generators, continuations, co-routines, ...
>
> For another fun use of "thisContext" check this Stack-Overflow question:
>
> http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project