I wrote some class comments, but somehow it cannot be merged in Pharo in a normal way.
Warning: 'You should not change blockclosure' or something like that I will check with Marcus later. 2013/7/25 Stéphane Ducasse <stephane.duca...@inria.fr> > Thanks. > Ok This is clear now - the outerContext is like my scheme environment. > This is what I was thinking but the examples I was trying (stupidly) where > just passing > the block as argument to different methods and they were not changing the > outerContext :) > > Clement will write some class comments and method comments and I'm > finishing the block chapter. > I will use this example because I realise that I forgot block nesting. > Stef > > On Jul 25, 2013, at 2:44 AM, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > > > > On Tue, Jul 23, 2013 at 2:02 AM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > >> thanks! >> It makes a lot of sense. >> I will play with another example because I want to really understand the >> outerContext of closure vs the home context. >> > > The outerContext is a link in the static chain. Each block is created > inside some context. This is the block's outerContext. If the block is > not nested then the outerCOntext will also be the home context But if the > block is nested inside another block activation, then the outerContext > refers to that block activation, and the block activation's block's > outerContext is the home context. So there are as many outerContext steps > as there are nesting levels. > > | homeContext b1 | > homeContext := thisContext. > b1 := [| b2 | > self assert: thisContext closure == b1. > self assert: b1 outerContext == homeContext. > b2 := [self assert: thisContext closure == b2. > self assert: b2 outerContext closure outerContext == > homeContext]. > b2 value]. > b1 value > > Ignore the "bN appears to be undefined at this point" and evaluate the > above. No assert fails. > > Draw a picture. > > >> Stef >> >> On Jul 23, 2013, at 6:58 AM, Clément Bera <bera.clem...@gmail.com> wrote: >> >> This is because of compilation optimization. >> >> 2013/7/22 Stéphane Ducasse <stephane.duca...@inria.fr> >> >>> Hi >>> >>> when I execute the following >>> >>> first >>> "Bexp new first" >>> | temp | >>> temp := 2. >>> [ temp. >>> thisContext inspect.] value. >>> ^ temp >>> >>> tmp in the inspector is nil and does not hold 2 and I was wondering why. >>> I thought that thisContext was returning the blockContext >>> In the outercontext of thisContext blockClosure, tmp is also nil. >>> >>> >> This is because here 'temp.' is evaluated for effect (the value is not >> stored anywhere) and it has no side effect (reading a variable cannot lead >> to a modification of state of another object). So the compiler removes it. >> As it is removed, it is the same as if it was not in the block. So the >> block cannot access temp. Now write 'temp:= #foo' or 'temp foo' you will >> get it. >> >> >>> first >>> "Bexp new first" >>> | temp | >>> temp := 2. >>> [ temp. >>> temp traceCr. >>> thisContext inspect.] value. >>> ^ temp >>> >>> output 2 on the transcript. >>> >>> In this case 'temp.' is still removed, but the value of temp still need >> to be copied in the block for ' temp traceCr.'.'temp traceCr' is also >> evaluated for effect, but has the side effect to output the transcript, so >> the compiler cannot remove it. >> >> Basically the is very few things that the compiler removes, and one of >> them is variable read for effect, because you are sure it cannot lead to >> any issue. >> >> >>> Stef >>> >>> >> >> > > > -- > best, > Eliot > > >
