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

Reply via email to