Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Currying

wiki.haskell.org

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Currying

#41

Post by ReleaseCandidat »

kerkeslager wrote: post #33

Currying is one of those things in Haskell that always makes me think that Haskellers were so preoccupied with whether or not they could , that they didn't stop to think if they should . In my limited Haskell experience, you can mostly ignore that functions are curried, but every once in a while, someone uses it, and it has never, in my experience, made the code easier to understand, because the currying happens impl…

Just a remark, currying is nothing that is special to Haskell, it's a general ML "speciality" including the syntax for function application of not using parens.

Which is because lambda calculus does not have functions with more than one parameter, I guess.

Re: Currying

#42

Post by Hirrolot »

skybrian wrote: post #11

When you pass some arguments to a constructor and then later, you pass some more arguments to a method, that’s equivalent to currying. Method calls are easier to read and work better with autocomplete.

The technique you describe requires us to predict what data should be partially applied (before actually using it), and what data should be applied and used immediately. In contrast, currying/partial application doesn't require this decision from us -- for this reason I consider the functional approach more flexible than the object-oriented one.

In addition to that, I don't always find the constructor/method approach more readable. It _can_ be readable, if you design your API with care; however, it is common to group related data into records in the FP world as well, which mimicks OOP constructors, in a sense.

Re: Currying

#43

Post by IshKebab »

yen223 wrote: post #21
IshKebab wrote: post #10

I always thought currying was a bad idea. It makes the code way less readable: * more difficult to distinguish arguments and return values (there's a reason most languages have distinct syntax for them) * it encourages you to put your arguments in an order that might not be the most logical And on top of that it only works for the last argument(s). Feels like a lot of disadvantages to allow an overly clever trick tha…

I much prefer partial application. It just makes more intuitive sense - you take a function with many arguments, "fix" some of those arguments, and get a new function out. No need to mess with argument ordering, or all that. It's a shame the only language that did partial application well is, weirdly, Python.

Partial application just means fixing some arguments. My point was you can do that easily using lambda functions.

I guess you were talking about `functools.partial`, which is basically the same as currying and also only works on the last arguments. It's better to use lambda functions.

Also Python is far from the only language to have a function like that, e.g. see C++'s `std::bind` which nobody* uses since lambdas were supported.

*standard HN disclaimer

Re: Currying

#44

Post by yen223 »

bPspGiJT8Y wrote: post #26
yen223 wrote: post #21

Earlier quoted context omitted.

I much prefer partial application. It just makes more intuitive sense - you take a function with many arguments, "fix" some of those arguments, and get a new function out. No need to mess with argument ordering, or all that. It's a shame the only language that did partial application well is, weirdly, Python.

In Gleam it also seems to be done well: https://tour.gleam.run/functions/function-captures/

That looks really cool, thanks for sharing

Re: Currying

#45

Post by kamray23 »

kerkeslager wrote: post #33

Currying is one of those things in Haskell that always makes me think that Haskellers were so preoccupied with whether or not they could , that they didn't stop to think if they should . In my limited Haskell experience, you can mostly ignore that functions are curried, but every once in a while, someone uses it, and it has never, in my experience, made the code easier to understand, because the currying happens impl…

I don't think currying happens without you asking to, though. It happens because it happens, it's part of the language, and it's something you implicitly keep in the back of your mind every time you see a function call. I don't program a lot in Haskell, only some maths things I sometimes might need since it is rather useful for that, but the concept of currying is so natural that it's constantly expressing itself in the code. Very rarely do you apply arguments and consider that to be a function call in itself instead of like, three function calls. And since partial application is so incredibly important to Haskell and other similar languages, without currying writing would be very difficult. Consider the actual simple example of

      gears = filter ((==2) . length)
            . map (neighbouringNumbers numbers)
            $ filter ((=='*') . fst) symbols
which without currying would have to look like

     gears = (\xs -> filter ((\x -> x == 2) . length) xs)
           . (\xs -> map (\x -> neighbouringNumbers numbers x) xs)
           $ filter (\(c,_) -> c == '*') symbols
It just makes partial application a lot easier, especially when this kind of code pops up all over the place.

Re: Currying

#46

Post by Simon_ORourke »

kerkeslager wrote: post #33

Currying is one of those things in Haskell that always makes me think that Haskellers were so preoccupied with whether or not they could , that they didn't stop to think if they should . In my limited Haskell experience, you can mostly ignore that functions are curried, but every once in a while, someone uses it, and it has never, in my experience, made the code easier to understand, because the currying happens impl…

> Currying is one of those things in Haskell that always makes me think that Haskellers were so preoccupied with whether or not they could, that they didn't stop to think if they should.

This had to be said! Sure you can make the argument that this improves your productivity as a coder, or makes the code more concise, but to someone coming along cold and trying to pick apart your code to fix something it's going to be a nightmare.

Re: Currying

#48

Post by dxdm »

082349872349872 wrote: post #16
solardev wrote: post #15

Earlier quoted context omitted.

You must've gone to a pretty kick ass elementary school. In mine, we'd play Connect Four and make paintings out of fake hieroglyphs...

I'm fortunate my parents didn't stick with free-to-play, but were willing to spend 5-6 digits more to buy a house in the "good" school district: https://news.ycombinator.com/item?id=39946026

Willing _and_ able.

Re: Currying

#49

Post by kerkeslager »

whilenot-dev wrote: post #36
kerkeslager wrote: post #34

Earlier quoted context omitted.

Are you saying this to be helpful, or just to show you're smarter? If you're saying this to be helpful, you should probably explain more. Currying is a subset of partial application, so I suspect the person you're responding to is just being a bit loose with their wording, as opposed to not understanding the topic.

I don't read it that way, no. Currying is a process to transform a function that takes multiple arguments into higher order functions that take one argument at a time to enable partial application (as written in the article). The partial application of a function is a different transformation of a function. Some languages provide partial application without currying a function - JavaScript has bind , Python has funct…

Okay, I understand what you're saying, and you're right, but you're missing my point and doubling down on the same mistake again.

Language is inherently imprecise and communication is never perfect. When people say something, it's rude to assume they are wrong or don't understand something because they don't say it exactly the way you would have said it. This is extremely common in technical communication and it's extremely counterproductive.

I'm suggesting that you could be a better reader by trying to understand what people are trying to say even if they don't communicate it exactly the way you want them to.

For example, no one in this comment chain is confused about what currying or partial application are, so it's a bit rude that you've assumed people are confused because you didn't take the time to figure out what people were trying to communicate. Instead, because people didn't say things exactly the way you would have said it, you jumped in with corrections.

If you take a step back and resist the urge to correct people, can you understand how "Currying is a subset of partial application" is true?

Re: Currying

#50

Post by kerkeslager »

ReleaseCandidat wrote: post #37
skybrian wrote: post #11

When you pass some arguments to a constructor and then later, you pass some more arguments to a method, that’s equivalent to currying. Method calls are easier to read and work better with autocomplete.

No, not exactly. And partial application of any function is nowadays possible using anonymous functions to wrap the original one, no need for constructors and special methods. What currying in Haskell and any other ML does, is the following as Javascript. Let's say we have a function with four parameters `func(a, b, c, d) {return a + b + c + d;}`, then the curried version is the following: func = (a) => { return (b)…

You're assuming that the poster doesn't understand what currying is and you're jumping in with a correction which is kinda rude.

Instead of assuming you know better and jumping in with a correction, could you reread that post and assume that the person knows what they're talking about but isn't communicating exactly the way you would have communicated it? I.e., read with the intent of understanding intent, rather than read with the intent of correcting?

Post reply on HN