<br><br><div class="gmail_quote">On Mon, Nov 29, 2010 at 12:43 PM, James Ladd <span dir="ltr">&lt;<a href="mailto:james_ladd@hotmail.com">james_ladd@hotmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">




<div>
<pre>Hi Eliot,<br><br>I was suspecting you might respond, you really know your stuff.<br><br>I think I&#39;m more confused now that before but in a good way. <br>I have more information thank to you.<br><br>My need to fully understand blocks is to implement them in Redline.<br>
<br>Maybe it will be sufficient to &#39;limit&#39; the use of a block with a <br>return to the method in which is was defined?<br>ie: Method A can define the block and send it as an argument, but once<br>method A has been exited, the block is no longer valid, at least not<br>
the return part. <br></pre></div></blockquote><div><br></div><div>Right.  That&#39;s what one gets with nested functions in Pascal.  One cannot return a nested function in Pascal because a nested function&#39;s lexical bindings are only valid within the enclosing activation.  This allows the implementation to refer to its lexical bindings by reference, either with a &quot;static chain&quot; or a &quot;display&quot;.  The static chain is the common implementation technique now.  The head of the static chain is a copy of the frame pointer of the next lexically-enclosing function, stored in the nested function and its activation.  Any lexical binding can be reached by following the static chain.  An alternative technique is a &quot;display&quot;, which is essentially an array of frame pointers, one for each level of nesting, allowing implementing lexical binding access by a double indirection.</div>
<div><br></div><div>But these are only &quot;downward funargs&quot; because they can only be passed down the stack.  Smalltalk (and many other languages) provides &quot;full upward funargs&quot; becaue they can outlive their enclosing activation and be returned.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><pre><br>Does this appear most &#39;like&#39; how blocks are handled in Pharo?<br></pre></div></blockquote><div><br>
</div><div>Sort of.  The main difference is that in Smalltalks derived from Smalltalk-80 activation records are first-class objects and so can outlive their invocation.  i.e. a Smalltalk activation is an object, /not/ space on a stack.  Under the covers the VM /may/ choose to implement activations in a stack-like manner, lazily creating objects only when needed (which is what Cog and VisualWorks do), but that&#39;s a hidden optimization and conceptually creating an activation creates an object.  So there is no conceptual problem having a block refer to its enclosing activation after that activation has returned, but obviously the attempt to return a second time must fail because the place to return to is already in use, or has already been returned from.</div>
<div><br></div><div>However, apart from return, there is no need to refer to the outer activation to access lexical bindings.  The scheme is to copy the values of lexical bindings that can&#39;t change while executing a block that refers to them (e.g. arguments and temps assigned to before a block is created but not afterwards), and move the lexical bindings that can change off teh stack into a heap-allocated Array.  You can read about this in excruciating detail on my blog in <a href="http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/">http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/</a>, <a href="http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecodes/">http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecodes/</a> and <a href="http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compiler/">http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compiler/</a>.</div>
<div><br></div><div><br></div><div>BTW, the Wikipedia page on the <a href="http://en.wikipedia.org/wiki/Funarg_problem">Funarg problem</a> is a good starting point for a general discussion of closures in programming languages.</div>
<div><br></div><div>HTH</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><pre><br>Rgs, James.<br><br><br></pre>                                               </div>
</blockquote></div><br>