Purely stack-based generators

[Regan Heath]

Norbert Nemec wrote:
> I really like that simplified, "yield"-based syntax. However, I believe 
> that it conflicts fundamentally with D's confusing concept of generators.
> 
> Most other languages that offer generators (e.g. Python) view the 
> generator as an object that spits out values one-by-one. This is very 
> similar to a co-routine.
> 
> Purely for performance reasons, D approaches the issue in a backward 
> way, passing the loop body as a delegate. Indeed, this may be faster 
> than full-fledged co-routines, but it is rather difficult to map a 
> simplified coroutine-like syntax based on 'yield' statements to this 
> very different concept by mere "syntactic sugar". Furthermore, the D 
> concept scales awkwardly to combining multiple generators in one loop or 
> using nested generators.
> 
> In fact, there is a simple but powerful way to design purely stack-based 
> generators, sticking to the straightforward concept of co-routines 
> without the overhead of full co-routines and without the need for 
> delegates (inspired by the Sather language):
> 
> Make a generator a co-routine but restrict its lifetime to the inside of 
> a loop. When the loop starts, it calls all the contained generators to 
> initialize their local data on the regular stack. When the generators 
> yield, the stack-pointer is *not* reset (as it would be at a return) but 
> kept at its value. The generator routines can therefore be called again 
> within the same loop and find their local data still on the stack. When 
> the loop finishes, the stack pointer is reset to its initial value and 
> all the local data of all the contained generators is immediately released.

So, these generators are essentially inline functions?

R