3 ms·

tl;dr Currying is nice when whitespace is function application and ugly and inconvenient when you have to write foo(x)(y) and the libraries you deal with aren'

• emodendroket 9y ago
  Did I miss something? I see no mention of white space in this article.
  • theoh 9y ago
    The article says "Most functional programming languages with automatic currying have syntax where there is no difference between add(1, 2) and add(1)(2)" and goes on to talk about unidiomatic syntax. In Haskell, the two options are "add (1,2)" and "add 1 2" The latter, curried form, involving whitespace, works because Haskell parses it as an application of a to 1, followed by an application of the resulting value to 2. This syntax is inspired by the lambda calculus, so it's not really whitespace that's the concept, just "juxtaposition of terms" implies application.
    • 59nadir 9y ago
      > In Haskell, the two options are "add (1,2)" and "add 1 2" The latter, curried form, involving whitespace, works because Haskell parses it as an application of a to 1, followed by an application of the resulting value to 2. This is a bit of a misrepresentation. There is nothing "uncurried" about using these parens here. It's simply making a function call on two parameters take a tuple of two values instead. There's no point to it at all and there's no real value in doing it in your APIs. I have no idea why the Haskell wiki insists on framing it like that. Using the "curried form" has no effect on how the function call will perform or behave at all. Partially applying functions can have performance implications, though.
      • theoh 9y ago
        Consider, though, the Haskell functions "curry" and "uncurry" which transform functions between these two styles. They are different types, so I don't see how it is a misrepresentation.
• chriswarbo 9y ago
  That only seems to be a minor issue. The author specifically mentions "simple currying" and "overloaded currying". Extra parentheses are only an annoyance with the former.