[cowbell]

It's also wrong :)

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.)

[tel]

As long as you have ordered parameters, I'm not sure this is such a big issue. First, tuples are (morally, i.e. up to non-termination) associative in most reasonable languages, so the product/exponential adjunction can be shifted around however you like

    -- 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

However, so long as you have parameter order (we're not allowed to commute our tuples, just reassociate nested tuples like ((a, b), c) <-> (a, (b, c)) and so on) then flip still morally works

    flip (someFn :: (a, b, c) -> d)
      :: (b, a, c) -> d
      :: (b, a) -> c -> d
      :: b -> a -> (c -> d)

The same story holds for partial evaluation. Of course, there have to be far more edge cases to handle all this tuple twiddling.

---

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.

[tel]

Also to explain that strange "adjunction" comment, currying results from the notion that the things of type

    (a, b) -> c

are exactly equivalent to the things of type

    a -> (b -> c)

An adjunction (F, G) occurs when the things of type (F a -> c) are equivalent to things of type (a -> G c), so if we pick F x = (x, b) and G x = (b -> x) then we see that currying is an adjunction between (,b) and (b ->).

[evincarofautumn]

One intuition for this is that (a, b) is the product type (a × b) and the function arrow (a → b) corresponds to exponentiation (b^a), so you get the isomorphism for free from the identity c^(a × b) = (c^b)^a.

[CrossEye]

Yes, freely admitted. (Author here.)

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)

works just as well in Ramda as

    var total = reduce(add, 0);  // or
    var sum = reduce(add, 0, numbers)

So, as I said, feel free to keep on insisting. :-)

[cowbell]

http://vimeo.com/96639840

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 :)

[CrossEye]

I finally got a chance to watch that video, and it looks as though what you're worried about is `flip`. Ramda for one already includes a version that works much like Haskell's. I don't know if this satisfies your objection, though.

[tel]

As I stated above... flip is well defined so long as your arguments are positional.

[comex]

This implementation of multi-argument partial application does not in any say prevent implementation of flip. It's just syntax sugar.