On 09/25/2016 01:06 PM, Chris Wright wrote:
On Sun, 25 Sep 2016 01:36:57 -0400, Nick Sabalausky wrote:
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.
Basically, yea. Soooooo much nicer than writing/maintaining inverted
code by hand!
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.
Ah. Yea, totally transparent they are not. But I find them to be a solid
enough abstraction that I have no issue whatsoever.
Keep in mind though, fibers and threads aren't really all that
transparent either, there's a bunch of behind-the-scenes magic there
too. Saving/restoring register state. Your threads will just *stop* at
arbitrary points while some other code halfway across the codebase is
executed. Etc. But they're solid enough as abstractions that we prefer
the abstraction to dealing with the underlying mess transparently.
The same applies to nearly all programming constructs, even something as
basic as function calls. Bunch of opaque hidden magic there. But it
pretty much *just works* so we rarely need/want the transparency.
[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.
That's why some solid abstraction magic would be very, very nice! :)
