[steveklabnik]

  > If foo takes many arguments we add more arrows, i.e. foo :: a -> b -> c
  > means that foo takes two arguments of types a and b and returns something of
  > type c.

Nitpick alert: since everything is curried in Haskell, it's actually more like `foo takes an argument a and returns a function that takes one b and returns one c`.

Other than that teeny thing, this article is awesome, and I fully agree. Promises are an excellent thing, and while I'm just getting going with large amounts of JavaScript, they seem far superior to me.

[threedaymonk]

> Nitpick alert: since everything is curried in Haskell, it's actually more like `foo takes an argument a and returns a function that takes one b and returns one c`.

Whilst that's true, and is important to the way in which Haskell operates, people normally talk about functions as taking multiple arguments (at least, the people at London HUG, most of whom are better Haskellers than I, seem to).

Even ghci refers to the "second argument":

    Couldn't match expected type `Int' with actual type `Char'
    In the second argument of `foo', namely 'b'
    In the expression: foo 1 'b'
    In an equation for `it': it = foo 1 'b'

[steveklabnik]

Of course, hence the 'nitpick alert' and admission that it doesn't really affect anything in the text, just a detail about how things work.

Often, conversations are not held to absolute rigor. Not every off-handed statement is absolutely consistent.

[andrus]

Really? Consider

    f :: a -> b -> a
    f a = g a
    
    g :: a -> b -> a
    g a _ = a

It doesn't seem right to say that g "returns a function that takes one b", whereas you could say that about f.

[steveklabnik]

Yes. http://www.haskell.org/haskellwiki/Currying

[andrus]

Thank you for clarifying! I did not know that all functions in Haskell are considered curried. My surprise stemmed in part from reading a bit about "arity" from [1].

It's interesting how the theoretical model of Haskell--"all functions in Haskell take just single arguments"--differs from implementation, where, for functions of known arity, GHC in particular does not actually "follow the currying story literally" [2].

[1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Hask...

[2] http://community.haskell.org/~simonmar/papers/eval-apply.pdf

[steveklabnik]

Any time. It's one of the more interesting parts of Haskell to me, so it's one I always remember.

You're absolutely right to point out that implementations and theory often differ; compilers often do tricky things behind the scences.

[Evbn]

(g a) is valid Haskell and it is equal to a constant function that returns a. In fact, g is the Prelude function 'const'.