<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'><br>I while ago, while studying Eliot's <a target="_blank" href="http://www.mirandabanda.org/cogblog/category/cog/page/14/">factorial copy example</a> I made the mistake of assuming that since the sender of the MethodContext was the UndefinedObject (which is the Nil object) that that was why the sender was nil.<br><br>Eliot corrected me, writing:<br><br><br><div><br><blockquote style="border: 1px solid rgb(204, 204, 204); padding: 7px; background-color: rgb(245, 245, 245);"><div>Assuming you're not joking, that's not what it means at all. <br>The sender points to the sender context *until* it is returned from. <br>We're inspecting a block, which got created in the Doit context for the expression [:n| ....]. <br>And that DoIt context is the home context of the [:n|...] block. <br>The DoIt context returned its result (the [:n|...] block) to whatever the sender context was. <br><b>But when the DoIt context returned that result the DoIt context's sender was nilled, to indicate that it had been returned from</b>. <br>So by the time the [:n|...] block was inspected its home context's sender was nil.<br></div></blockquote> <br><br><br><br></div> <div>I spent some time trying to figure out exactly where that happens and I believe I have followed it to "system space" where I would like to leave things for now. If I am in fact correct.<br><br>Following the code of Eliot's <a target="_blank" href="http://www.mirandabanda.org/cogblog/category/cog/page/14/">factorial copy example</a>, The DoIt travels through user space, to the Compiler's <br><br><b>Compiler >> evaluate: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag</b><br></div><br>and ends up at <primitive:188> in <b>Object >>withArgs: argArray executeMethod: compiledMethod</b><br><br>{A whole bunch of stuff happens in System Space that I am do not know how to trace yet--but eventually, the return must happen....so..}<br><br><br>In the BlueBook on page 608, There is a section on Return Bytecodes where bytecode 123 does set the sender nil.<br><br><br><br><br><blockquote style="border: 1px solid rgb(204, 204, 204); padding: 7px; background-color: rgb(245, 245, 245);"><div>returnBytecode<br> currentBytecode = 120<br> ifTrue: [tself returnValue: receiver<br> to: self sender].<br> currentBytecode = 121<br> ifTrue: [tself returnValue: TruePointer<br> to: self sender].<br> currentBytecode = 122<br> ifTrue: [tself returnVatue: FalsePointer<br> to: self sender].<br><b> currentBytecode = 123<br> ifTrue: [tself returnValue: NilPointer<br> to: self sender].</b><br></div></blockquote> Which exists on Squeak's Interpreter and is mapped to instance method <br><br><b>Interpreter >> returnNil.</b><br><br><br><br>and finally, <b>Interpreter >> commonReturn</b> <br><br><br>that seems the most possible path to me.<br><br>Conversely, any possibility of the sender being nilled in User Space would have to call <b><br>ContextPart>>privSender:</b> <b>aContext </b><br><br><br>Browsing the senders of that method paired with no apparent semaphores in the Compiler method, leads me to conclude it happens in system space.<br><br>Does that sound like its in the ballpark? Details are not neccessary as my goal was to just account for every variable we see in a Context.<br><br>thx<br><br>tty<br></div></body></html>