fn(a, b) === fn(a)(b)for Ramda functions. To say its the same except for certain non-commutative operators was problematic. And we probably couldn't just say binary functions, either, or would you expect
lt, like I explained. It's not the end of the world, but Ramda's argument order has started to make a lot of sense to me, until I met
ltjust now. :P
gte, etc. We had
divideBy, and such, but no good names for these.
R.lt(7, 12)just seems to me it should return
divide(20, 5)should return
fnucwas built around trying to solve this issue, but I think it ends up somewhat incoherent.
R.lt(6)to test if the following value is less than 6. I think I've even used it like that to explain currying to colleagues. :P
R(x), all of Ramda's functions are partially applied with
x, and the results are returned in an object. That's an interesting way of doing things. :P
R.pipe, there's nothing special about Ramda functions; you can pass anything you want. So, while you could do something like `R(3).someRfunc, the only way I know to make it more generic so that you could apply any other function you like is with a stateful registration process.
Ritself as the function.
R.maptakes it's data last, because it's a much more common case to want to create a partially applied
mapwith a mapper, than it is to create a partially applied map with it's data, waiting for different mappers to be passed-in
fnucsince I first saw it. But I've never been quite convinced.
map(square)seems an obvious abstraction, and currying is familiar to most functional programmers in that format.