Hacker News Reader

Comment by pflanze | Hacker News Reader

Any reason why not to implement call/cc and then write fibers in terms of call/cc? The implementation may not actually be any different from what it is. (I've not studied the code enough to understand how it implements fibers, although I got the impression that it handles call frames explicitely (source/fargo/runtime/stack{,less}.js).)

View on HN

I was going to do call/cc but fibers are cheaper. The implementation is very similar, but because fibers can only be resumed once from the last yield you don't need to copy the stack when yielding and resuming.

They also require the user to explicitly start a fiber. This means when you're not in a fiber you can use a faster stackless engine because you don't need to track the state of the current continuation.

> explicitly start a fiber

Fair point.

BTW what's interesting about yield based versus lazy evaluation (functional stream) based sequence generation? Advantages of the latter are that they can easily be understood as sequences and thus further processed by lazy versions of the known sequence processing functions (map etc.), also they can be re-read multiple times, which you just made impossible for yield by not basing it on call/cc :).

I've been thinking about this. I might try out making all the primitive functions understand promises. So not lazy evaluation per se, but having the core library transparently deal with asynchronous values. Maybe monads would help but that really requires a decent type system.

Reply on news.ycombinator.com