Interesting: as far as I can, this is promises, except there is a final strictness point at the end of the composition. That is, in turn, analogous to a one-shot form of old FRP formulations, where there is a final strictness/execute call. We already see that in JS libraries, like 'subscribe' in Rx: <a href="https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/subscribe.md" rel="nofollow">https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...</a><p>FWIW, I'm actually not that thrilled about this sort of deferred approach. In Rx, that is part of the reason 'hot' vs 'cold' documentation has to exist, and I've seen many people struggle with it in theory & practice.
As you start to look at these concepts, and Ramda, I highly recommend playing with ramda-fantasy[0] and the fantasy-land[1] spec that it implements. Super useful, and really made this sort of functional programming "click" for me (and, has really cleaned up some abstractions in a couple production projects, too!)<p>[0] <a href="https://github.com/ramda/ramda-fantasy" rel="nofollow">https://github.com/ramda/ramda-fantasy</a><p>[1] <a href="https://github.com/fantasyland/fantasy-land" rel="nofollow">https://github.com/fantasyland/fantasy-land</a>
Note his call back hell is exacerbated by the unnecessary 'else' after checking for errors and returning.<p>I'm not sure that .bindTo() chaining reads any better than .then() chaining or async.waterfall().
I was recently thinking while working with ES6 Promises that I liked to have something equivalent to Haskells `do` notation. Or Scalas `for` comprehension.<p>Does something like that exist?<p>If not maybe I should try Kleislis instead. But I'd like my code to be accessible for my colleagues. And it's my rule of thumb that I try not to use point free constructions (like Kleislis) because a lot of colleagues will no longer understand my code easily.