Add implementation for scanP

Hi Ramda folks!

I recently ran into a situation at work where I needed to use R.scan asynchronously, using promises. I wrote an implementation, and was wondering if there was any interest in getting it into the library.

---

Usage

The type signature would look something like this scanP :: (a,b -> Promise a) -> a -> [b] -> Promise [a]

In use, it would work just like the regular R.scan

Regular R.scan

R.scan(R.add, 0, [1, 2, 3]);
// [0, 1, 3, 6]

scanP

const addAsync = (a, b) =>
  Promise.resolve(a + b);

scanP(addAsync, 0, [1, 2, 3]);
// Promise [0, 1, 3, 6]

---

Does anyone think this has a place in the library? I’m happy to submit a PR if so.

[asaf-romano]

I guess it’s time to be the devil’s advocate.

In our code base we have thatP (promise) variants for many of Ramda’s functions (as well as promise variants of our own additions). They are invaluable in a modern, heterogeneous js environment in which functional code must integrate with common external libraries (db drivers, queue systems etc) and also with the fact the Promises are rapidly becoming first class citizens in vanilla JS, the DOM and in the JS ecosystem in general. Ironically, our JS code base would probably be much less functional if it weren’t so easy for us to make the integration with imperative code seamless.

For instance, consider an API built on top of applySpecP (~~ applySpec + Promise.props). It can effortlessly integrate with imperative code in two important ways: On the one hand, an imperative consumer may await its result (especially useful alongside destructing assignment!) , Promise.all it with something else, etc. On the other hand, a property in the spec passed to applySpecP may be a messy async function implemented by someone else (or just you in the imperative day of the week). The only rule both sides have to follow is “public” immutability in their contracts - but at least from our experience that’s a very low bar now and, surprisingly almost a consensus.

This is very much in the spirit of the language in general, which makes it quite easy to mix and match very different paradigms without much hassle. That’s, as they say, one of the good parts about this language. The practical benefits of futures/tasks could never match this convenience. After all, there are many way to get good results - should FP require us to continuously worry about external dependencies or commit to a homogeneous code style, we would simply have to avoid it altogether. Interoperability is king.

So while I agree with the other maintainers that promises are a pretty strange, black sheep in the functional world, I think the value of playing nice with promises outweighs the shortcomings. Having said that, implementing all those P variants required relatively little effort, and most of the time we were able to rely on the built-in variants without re-implementing core functionality. It did not require us to fork the library or monkey-patch anything. That’s why I generally feel fine being the quiet minority on this subject.

---

• Well, we do have a better implementation of pipeP - but that’s all, I Promise.

[buzzdecafe]

Well argued, @asaf-romano . This is one of those things I would like to see out of the core lib, but pluggable when needed.