September 06, 2006
Steve Horne wrote:
> On Tue, 05 Sep 2006 21:24:39 -0400, Marcio <mqmnews123@sglebs.com>
> wrote:
> 
>> Walter Bright wrote:
>>>> One of the things needed for sure is heap frames.
>>> That's right, instead of using the stack for the locals, the heap is used. It isn't that much different from using a functor. In fact, now that I think about it, a functor might be a better way to do it than yield.
>>
>> 	Smalltalk blocks, basically.
> 
> I don't think so.


	I was saying a functor would be a smalltalk block. But I still inquire if that is really enough for generators, and I am not sure. So, we are not disagreeing (you and me). Maybe we are disagreeing with Walter's claim that just a functor is enough.

	Having said that...

> For each instance of a generator, you need a complete separate stack.
> That stack is kept on the heap, separate from the normal processor
> stack. Both have to be full stacks, since both contexts need to
> support function calls - even recursion - independently. Even though
> the generator itself is likely to be a single function with yields
> done directly from itself, it still needs to call normal functions to
> do its stuff.
>

	... Perhaps the caller will see its runtime stack used by the generator as it runs until its next yield/return. So, the environments are maintained in the heap and survive the return (therefore values of variables are remembered) while the stack used between 2 yield/returns is borrowed from the caller's stack. So, in this case Walter would be right.

	Anyway, that is why I was curious about code generation tricks. I guess one can always use C# 2.0 and check the IL code it generates.


> But first, Walter needs to concentrate on achieving immortality, so he
> has time to do all this ;-)


	Exactly!! :-)

marcio
September 11, 2006
	Indeed a single stack can be used if you impose limitations. See what Barbara Liskov says in "A History of CLU":

http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf#search=%22A%20History%20of%20CLU%22

3.10. Iterators
"Iterators are related to coroutines; the iterator and the body of the for loop pass control back and forth.
However, their use is limited so that CLU programs can make do with a single stack."
[...]
"Imposing the limitations on iterators was done to get the efficient, single stack
implementation, albeit at the expense of some expressive power."

And she credits the original invention to Alphard:
[Shaw, 1977]
Shaw, Mary, William Wulf, and Ralph London, Abstraction and Verification in Alphard: Defining and Specifying Iteration and Generators, Communications of the ACM, 20:8, August 1977.

marcio

Marcio wrote:
>     I was saying a functor would be a smalltalk block. But I still inquire if that is really enough for generators, and I am not sure. So, we are not disagreeing (you and me). Maybe we are disagreeing with Walter's claim that just a functor is enough.
> 
>     Having said that...
> 
>  > For each instance of a generator, you need a complete separate stack.
>  > That stack is kept on the heap, separate from the normal processor
>  > stack. Both have to be full stacks, since both contexts need to
>  > support function calls - even recursion - independently. Even though
>  > the generator itself is likely to be a single function with yields
>  > done directly from itself, it still needs to call normal functions to
>  > do its stuff.
>  >
> 
>     ... Perhaps the caller will see its runtime stack used by the generator as it runs until its next yield/return. So, the environments are maintained in the heap and survive the return (therefore values of variables are remembered) while the stack used between 2 yield/returns is borrowed from the caller's stack. So, in this case Walter would be right.
1 2
Next ›   Last »