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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
