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.