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