September 06, 2006 Re: Walter: any plan to add support for yield/return Iterators/generators? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steve Horne | 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 Re: Walter: any plan to add support for yield/return Iterators/generators? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marcio | 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. |
Copyright © 1999-2021 by the D Language Foundation