Don't curry internal functions about ramda HOT 3 CLOSED

We're looking at (very soon) switching to manual currying of these internal functions for performance reasons. So, while that's an interesting idea, it may not be necessary.

On the other note, we are not trying to match the APIs of other libraries necessarily, or of the native prototypes, especially if what they have seems wrong or harmful. It's about the classic sorts of examples:

_.map(["1.1", "2.2", "3.3"], parseFloat); //=> [1.1, 2.2, 3.3]
_.map(["1", "2", "3"], parseInt); //=> [1, NaN, NaN]

Because Underscore.map (like the native Array.prototype.map) passes the index as the second parameter, but parseInt expects a radix.

R.map(parseFloat, ["1.1", "2.2", "3.3"]);  //=> [1.1, 2.2, 3.3]
R.map(parseInt, ["1", "2", "3"]); //=> [1, 2, 3]

Yes, we could clear this up with nAry or the newly added unary:

R.map.idx(R.unary(parseInt), ["1", "2", "3"]); //=> [1, 2, 3]

This feels the wrong direction to me for an FP library.

from ramda.

For max performance you will want to limit composition (currying requires wrapping thus a form of composition) while for terser code composition is great. Currying isn't needed to do most of the composition internally but will kill performance regardless of how well its tuned.

Currying the exposed API seperately is the best IMO

from ramda.

You can see what we did to where to reduce some of the overhead. The plan is to do this across the codebase. It will be uglier, but will gain performance for all users of the functions, not just internal users. So for instance:

var prop = function(name, obj) {
    return arguments.length === 0 ? 
           prop                   : 
           arguments.length < 2   ?
           function(obj) { return obj[name]; } : 
           obj[name];
};

You can see this in action at http://jsperf.com/ramda-auto-curry-cost/3

from ramda.