[OT] Stackless fibers/coroutines

[Chris Wright via Digitalmars-d]

On Sun, 25 Sep 2016 01:36:57 -0400, Nick Sabalausky wrote:

> On 09/24/2016 09:14 PM, Chris Wright wrote:
>> On Sat, 24 Sep 2016 11:49:24 -0400, Nick Sabalausky wrote:
>>> My understanding is that C#'s coroutines, under the hood, work the
>>> same way as C's Protothreads library:
>>
>> You mean async/await, which is a compiler-provided CPS transformation
>> on top of the Task API.
>>
>>
> No, I mean "yield". My C# work was all before async/await.

Ah, I'd heard about people doing that.

That's a different transformation. Method to method object, add a state 
variable to mimic the program counter, and munge things about enough to 
match the IEnumerator interface.

Surprisingly similar despite the differences in implementation, though.

> The "turning functions inside-out" effect of continuation passing is
> exactly what input ranges suffer from[1] - and is exactly what stackless
> coroutines *avoid*.

The compiler inverts them for you.

>> Fibers are more convenient. They also have a large, upfront cost, but
>> they have the advantage of treating the stack like a stack. It breaks
>> fewer assumptions about performance.
>>
>>
> You may want to give C's protobuf or C#'s yield-based generator
> functions a try. Yes, true, they're not as convenient as actual fibers,
> but there's a LOT they let you do painlessly (far more painlessly than
> writing input ranges[1]) without the fiber overhead - think opApply but
> without the complete and total incompatibility with functions that
> operate on ranges.

Yeah, I really want something transparent.

> [1] Note I mean actually writing an input range itself. *Using* an input
> range is wonderfully pleasant. But writing them turns all my logic
> inside out, somewhat like Node.js-style callback hell (or ActionScript2
> back in my day).

Agreed. It's relatively easy to compose ranges, which is nice, but 
whenever I have to write one from scratch, I get a little sad.