[Haskell-cafe] Real World Haskell: confusion

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