These are chat archives for ramda/ramda
@olsonpm my pleasure
eh, isn't chain map and chain simultaneously?
I could have been a lot clearer when I said that.
R.chain( multiply(2) , 2 ) //=> undefined R.map( multiply(2), 2 ) //=> 4 R.chain( multiply(2) ,  ) //=> 4 R.map( multiply(2),  ) //=> 
The behaviours of map and chain are explicit. Chain transforms and unwraps, map only transforms.
chain requires the output of the visitor to be a monad,
map expects the output of the visitor to be a value
then handles both cases, if you return a Promise, then the next
.then will receive a value (like chain) and if you return a value, the next
.then will receive a value (like map). This doesn't really seem to matter for promises because the Promise API is specific to Promises.
But if Promise's used
chain and didn't automatically squash containers, we could compose Promises easily with other monad's ( like streams for example). Currently that is awkward, but it didn't have to be.
I think the A+ spec didn't account for more and more monadic types entering the language and interop being important.
It is likely we'll have Observables (can't stand that name) soon. And there will probably be more Monads added as the language evolves. It is forseeable after Observables we will get a synchronous Optional/Result/Maybe type as that is now pretty standard even in OO languages like C# and Java.
It is a shame that each API will probably be an island.
Seems like most.js makes the same distinction you are making in its chain implementation
concatMap concatenates, while chain merges.
is there a comprehensive reason for select functions in the list category working with objects as well as arrays? I didn't realize some of the function signatures are wrong until now (declare Array when object works fine).
for example, why won't forEach take an object but filter will?