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