[Haskell-cafe] Real World Haskell: confusion

[Anton van Straaten]

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