Internal and external iteration, fibers

[Nick Sabalausky]

On Tue, 15 Jan 2013 13:52:10 +0100
"bearophile" <bearophileHUGS at lycos.com> wrote:
> 
> In D the Range static protocol of iteration is external and 
> opApply is internal. Some persons have suggested to use fibers in 
> D to introduce a very handy "yield" syntax for internal iteration.
> 

D has problems in this area, there's at least three ways to do it and
yet all of them have major downsides:

opApply: The result is NOT usable as a range; it's strictly
foreach-only. Also: Unintuitive function signature, "yield" must become
"mixin(yield...)", and you need to create a dummy struct for it to sit
in.

Fibers: Too much performance overhead to be a general solution. Only
good for, as an example, heavily I/O-bound stuff.

Custom Input Range: Technically amounts to a co-routine, but is created
using an awkward event-loop style. The event-loop style is
necessary for Bidirectional/Random-access/etc ranges to be possible, but
this is an artificial constraint for input (and maybe even forward)
ranges.

Then there's C/C++ which has libs that offer what are known as
"stackless fibers". These utilize the preprocessor, along with switch
and goto, to accomplish the same thing that (AIUI) C# does for its
coroutines: It lets the user write a normal coroutine, with a normal
yield, which then gets trivially rewritten behind-the-scenes into an
event loop (with NO actual fibers involved). I'm not sure to what
extent this would be possible in D. If it is, the lack of preprocessor
would probably make it much less nice-looking to use than the C/C++/C#
versions. (Not that I'd want a preprocessor.)

So what D really, REALLY needs (this is one of the top things on my
wish list for a hypothetical D3) is real coroutine syntax which, much
like C#'s coroutines and C/C++'s stackless fibers, gets trivially
rewritten behind-the-scenes into a switch-based event loop, BUT this
coroutine would actually count as an input range.

tl;dr: D's input ranges are much more awkward to create than they
actually NEED to be, but the existing workarounds all have big problems.


> I think similarly short but clear article, about D Ranges and 
> opApply should be added in the articles 
> (http://dlang.org/articles.html ) section of the D site.
> 
> Bye,
> bearophile