Derek Elkins wrote:
No, it means exactly what you said it means. People abuse it to mean the second sense. Those people are wrong and there is already a term for that second sense, namely "partial application." I really wish people would stop conflating these terms*, all it does is create confusion.
+1
* A related annoyance is people who talk about languages "supporting currying and/or partial application." Unless one means that the language supports higher order functions at all by that, it doesn't make any sense. Haskell has no "support" for currying or partial application. The fact that most functions are in curried form in Haskell is merely a convention (with, admittedly strong -social- ramifications.) The only way one could say Haskell "supports" currying is that it has a lightweight notation for nested lambdas.
Compared to most other languages, that lightweight notation makes enough of a difference that it's reasonable to say that Haskell "supports currying and partial application". E.g., in Haskell: f x y z = ... Haskell without the above notation: f x = \y -> \z -> ... Javascript, to underscore the point: function f(x) { return function (y) { return function (z) { ... } } } "Standard" Scheme: (define (f x) (lambda (y) (lambda (z) ...))) Scheme with a common macro to "support currying": (define (((f x) y) z) ...) That's just the function definition side. On the application side, Haskell has a lightweight notation for application in general, i.e. you write "f a b c" instead of e.g. "f(a)(b)(c)" in C-like syntaxes or "(((f a) b) c)" in Lisp-like syntaxes. Together, these two sugary treats make it quite a bit more convenient and practical to use currying and partial application in Haskell (and ML, etc.), and this translates to *much* more use in practice. Anton