I think this, along with the whole article, is the best explanation of currying I've seen on the whole damn internet.
http://www.uncarved.com/blog/not_currying.mrk
Which the author freely admits:
(Some will insist that what we're doing is more properly called "partial application", and that "currying" should be reserved for the cases where the resulting functions take one parameter, each resolving to a separate new function until all the required parameters have been supplied. They can please feel free to keep on insisting.)
-- all morally identical
a -> b -> c -> d
a -> (b -> c -> d)
a -> (b -> (c -> d))
(a, b) -> c -> d
(a, b, c) -> d
((a, b), c) -> d
(a, (b, c)) -> d
flip (someFn :: (a, b, c) -> d)
:: (b, a, c) -> d
:: (b, a) -> c -> d
:: b -> a -> (c -> d)
---
Really, I think it's pretty meaningful to blur the distinction between "curry (once)" and "curry repeatedly along with tuple reassociation". The later forms an equivalence class of function types which all have the same application behavior.
(a, b) -> c
a -> (b -> c)
I feel that although the distinction can be very important, it's much less so for Javascript. And the implementation in Ramda can be used that way any time you choose:
var total = reduce(add)(0); // or
var sum = reduce(add)(0)(numbers)
var total = reduce(add, 0); // or
var sum = reduce(add, 0, numbers)
Start at 26mins. You don't have flip. You lose control over partial application. It isn't curry. You're right. It is an important distinction :)