Open eliperelman opened 10 years ago
I can say that it's worked well for Ramda, which made the decision to do so from the beginning. In fact, having a library that incorporated easily composable curried functions was really the main goal of Ramda.
It looks as though all the functions in fn.js already have their parameters ordered well for currying, so it should be straightforward to do.
A word of warning, though. When Ramda started to get some attention, it became immediately clear that Ramda's curry implementation needed work for performance reasons. We got through that, but it wasn't a fun two weeks.
I'd be very excited to see fn.js do this also.
Totally agree that this should be done. I was surprised this wasn't the case. Is there any downside to it?
The only downsides I see is that functions are heavier.
I think this should be added. initially without too much consideration to performance. Work toward setting the correct ordering of parameters etc. Then optimise the functions once we have a way of creating performance metrics
operations that act on collections should take either 2 arguments or 1 argument that is a collection. concat([1], [2]) // => [1, 2] concat([[1], [2]]) // => [1, 2]
After using fn.js for a bit now, I'm starting to wonder if I regret not making most methods auto-currying. I'm considering making this change for 1.0 and would welcome comments for or against based on your experience.