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

51–60 of 134 posts

Re: Currying

#51

Post by aebtebeten »

dxdm wrote: post #48
082349872349872 wrote: post #16

Earlier quoted context omitted.

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.

I grew up during the Cold War, so I don't know what the Young Pioneers were learning*, but we were good little capitalists, and we learned the Golden Rule:

"Whoever has the gold makes the rules"

(*maybe the ones who spent their summers at Artek were learning "whoever makes the rules has the gold"?)

Re: Currying

#52

Post by kerkeslager »

Hirrolot wrote: post #40
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.

Currying and partial application are dualities (think of them as function introduction/function elimination), so neither subsumes the other one. However, I agree with the wording of the original comment: when you _pass_ some arguments to a constructor and then to a method, this is (at least conceptually) partial application.

> Currying and partial application are dualities (think of them as function introduction/function elimination), so neither subsumes the other one.

Could you say more? I'm not sure I understand what you're saying here.

Re: Currying

#53

Post by kerkeslager »

ReleaseCandidat wrote: post #41
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.

Yeah, I'd attribute this to the lambda calculus, for sure.

And in the lambda calculus, it makes a ton of sense, because it allows you to break proofs into smaller chunks more easily.

But in a general-purpose programming language where the proofs are automated, I think this just makes the code less communicative of programmer intent.

Re: Currying

#54

Post by whilenot-dev »

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

Earlier quoted context omitted.

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 ex…

> ...can you understand how "Currying is a subset of partial application" is true?

It isn't true and i can understand why someone would make that statement. Currying and partial application both come from a functional mindset that treats functions as data, and like data also functions can be transformed.

Currying and partial application both satisfy a transformation depending on a desired context:

  - Currying "widens" a function "up" (as in you don't need to know all arguments beforehand in the same context anymore)
  - Partial application "narrows" a function "down" (as in arguments are contained within the context of the partially applied function)
"Currying is a subset of partial application" is true in the same sense as if "subtraction is a subset of addition". Sure, you can subtract negative values to have addition and add negative values to have subtraction, but that can't be your point, is it?

> If you take a step back and resist the urge to correct people...

Please keep it on topic.

Re: Currying

#55

Post by xeonmc »

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

Earlier quoted context omitted.

I think you confuse currying with partial application.

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.

Currying wraps, partial application unwraps.

Re: Currying

#56

Post by whilenot-dev »

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

Earlier quoted context omitted.

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 ex…

> no one in this comment chain is confused about what currying or partial application are

I can't agree here either... I know it from my own experience when i first learned about currying and partial application.

Re: Currying

#57

Post by kerkeslager »

kamray23 wrote: post #45
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…

> 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.

Eh, but that's my point: I want less cognitive load. Currying is another thing that I have to keep in the back of my mind, and Haskell already has way too many of those, and it's not a particularly useful thing. I've got limited space in the back of my mind for things and if I'm going to keep things in the back of my mind I want them to be useful. I mean, if your argument in favor of currying is that it saved you a few keystrokes in that example, color me unimpressed.

Maybe I'm just too stupid to understand easily, but the "simple" example you're giving is taking me a while to understand. If a junior dev on my team submitted that in a PR I'd send it back asking them to break it up into a few smaller named functions and probably not use a partial application at all. Something like "I know it's fun to be clever but let's make this easier for the next person who has to figure out what it does".

I guess what I'm saying is that for that example it seems like you're going for tersity rather than clarity for future readers of the code. If you were going for clarity you probably wouldn't write it either of the ways you've given.

And in big projects clarity is the number 1 concern[1]. In toy examples like this I can slog through and figure something like this out, but when it's 30 functions written like this, all calling each other in the most clever ways possible, nobody can figure it out.

[1] EDIT: Okay #2 after correctness perhaps. But it becomes hard to achieve correctness without clarity as a project grows.

Re: Currying

#58

Post by threatofrain »

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…

I thought it was somewhat the reverse — that the original motivation was to simulate multi-arity functions in a setting that only allows unary functions.

Re: Currying

#59

Post by ReleaseCandidat »

kerkeslager wrote: post #50
ReleaseCandidat wrote: post #37

Earlier quoted context omitted.

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 tha…

> but isn't communicating exactly the way you would have communicated it?

My answers are almost always less intented for the person who's post I'm responding to, but more for a general audience. As others have already posted the part about "currying isn't partial application", and I mainly wanted to add a (hopefully) understanable example.

And I would say that taking the OP's post as if he doesn't exactly know, what currying means in comparison to partia application _is_ the more favourable interpretation of their post.

Re: Currying

#60

Post by kerkeslager »

whilenot-dev wrote: post #54
kerkeslager wrote: post #49

Earlier quoted context omitted.

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 ex…

> ...can you understand how "Currying is a subset of partial application" is true? It isn't true and i can understand why someone would make that statement. Currying and partial application both come from a functional mindset that treats functions as data, and like data also functions can be transformed. Currying and partial application both satisfy a transformation depending on a desired context: - Currying "widens"…

> It isn't true and i can understand why someone would make that statement

It is true, and you are smart enough to understand it if you stop assuming you're the only one who understands the topic. I'm specifically sticking with the wording "Currying is a subset of partial application" to make the point that you can understand what someone is trying to say even if they don't say it exactly the way you would like them to say it.

> - Currying "widens" a function "up" (as in you don't need to know all arguments beforehand in the same context anymore) > - Partial application "narrows" a function "down" (as in arguments are contained within the context of the partially applied function)

So you're saying that I'm "widening" the function "up" when I do:

    increment = add 1
    invert = div 1
...? But I'm "narrowing" the function "down" when I do:

    increment = (\x -> add 1 x)
    halve = (\x -> div x 2)
...?

When I curry `add` above, isn't the argument 1 contained within the context of the partially applied function?

When I partially apply `div` above, don't I no longer have to know all the arguments (i.e. I no longer need to know the denominator 2)?

It sure seems like this up/down wide/narrow wording you're fixated on isn't a particularly better descriptions of what's going on with currying and partial application.

It mean, maybe it's just my font, but the partial applications are a bit wider on my screen. ;P

> "Currying is a subset of partial application" is true in the same sense as if "subtraction is a subset of addition". Sure, you can subtract negative values to have addition and add negative values to have subtraction, but that can't be your point, is it?

I'm not sure I understand that analogy to say it's my point.

Are you saying you would behave condescendingly toward someone who said "subtraction is a subset of addition" too?

> Please keep it on topic.

The topic skybrian started was derailed when you decided to "correct" him because you didn't make any effort to understand what he was trying to say. Your behavior is the topic now because your behavior became a problem.

Post reply on HN