Hacker News Reader

Comment by skybrian | Hacker News Reader

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.

View on HN

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.

Yes, like many refactorings, rewriting a function as an immutable class with a method is not always a win. It depends on how you want to group a function’s parameters, whether that grouping has an intuitive name, and whether you might want to write other methods that take the same initial parameters. Sometimes grouping parameters using a record type is better, though you don’t get the nice syntax.

If currying isn’t built-in, you can emulate it. In TypeScript you need to do it explicitly, which means anticipating that it will be used, and whenever I try that, I later decide that it’s needlessly obscure and rewrite the code some other way.

Even with built-in currying, you still need to anticipate usage by changing the order of the parameters, based on which ones you expect the callers to have first. It’s less general than writing an inline function with exactly the parameters you need. TypeScript has nice syntax for defining tiny, one-off functions and I think that’s better than having currying.

One side-effect of having currying in a language is that it discourages naming things, and I think that’s often bad for readability. A chain of method calls gives you a lot of names to look up and a place to put documentation.

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) => {
       return (c) => {
         return (d) => a + b + c + d;
      } 
     } 
    }

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?

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

> My answers are almost always less intented for the person who's post I'm responding to, but more for a general audience

Same. I don't expect you're going to admit your mistake, but I'm pointing it out because the general audience is the sort of audience who is prone to this mistake (which I only know because I myself have been corrected for making this mistake).

> As others have already posted the part about "currying isn't partial application", and I mainly wanted to add a (hopefully) understanable example.

And in doing so, you're making the same mistake as those other posters, by assuming skybrian doesn't know what currying and partial application are. You're not doing your audience any favors by painting skybrian's post as if he said something wrong.

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

How so?

It's ironic that your responses come off as much more rude and condescending than the comment in question.

I’m not offended. I was too brief and I can see how my post could be misleading.

Peak HN meta-argument.

It is easy to guess that the original comment meant that a manual re-write of a function:

    foo(a,b) {...}

to a class (example in pseudo-C++, since C++ supports operator() overloading):

    class Foo {
        Foo(a) {...}
        operator()(b) {...}
    }

is equivalent to currying the original function:

    // curried foo:
    foo(a)(b)

    // class-curried foo:
    Foo(a)(b)

But instead of explaining or mentioning this, you both went into a rant about intentions and motivations, which completely bored me, and informed me of nothing, as a member of the general audience.

Congratulations.

Thank you for bringing the topic back on track!

Your example is currying in a manual fashion, so two questions remain for me:

1. How would you tell the compiler to do it for you, as a function transformation?

2. How would you curry a function with 3+ arguments?

I can answer both questions with a sprinkle of template magic:

    #include <iostream>
    #include <functional>

    template <typename Ret, typename First, typename ...Rest>
    class Curry {
        std::function<Ret(First, Rest...)> fn;
      public:
        Curry(std::function<Ret(First, Rest...)> fn): fn(fn) {};
        Curry<Ret, Rest...> operator()(First arg) {
            return Curry<Ret, Rest...>{[this, arg](Rest... args) {
                return this->fn(arg, args...);
            }};
        }
    };

    template <typename Ret, typename Arg>
    class Curry<Ret, Arg> {
        std::function<Ret(Arg)> fn;
      public:
        Curry(std::function<Ret(Arg)> fn): fn(fn) {};
        Ret operator()(Arg arg) {
            return this->fn(arg);
        }
    };


    int uncurried(int a, int b, int c) {
        return a + 2*b + 3*c;
    }

    int main() {
        auto curried = Curry<int, int, int, int>{uncurried};

        std::cout << curried(1)(2)(3) << std::endl;
    }

I'm speechless, thank you very much! =)

It is clear that that poster does not understand what currying is, as defined in the first line of the article and easily found online; also, downthread [1], nor do you. Currying is when you turn a function of multiple parameters into nested functions of single parameters. Partially applying a curried function is not called currying.

Though if enough people share the confusion, I guess it becomes an alternative definition. Language evolves.

Also, in any case, a constructed object is nothing like a partially applied function, so the parallel drawn is not useful. It seems entirely reasonable in this case to assume that the poster does not have sufficient experience or knowledge.

[1] https://news.ycombinator.com/item?id=39959651

I can see how someone might think I don’t know the difference, but it’s rather that I don’t think the details are important. They are both ways of partially applying a function. I wanted to demystify currying and show the equivalence, but I was too brief about it.

A method is a function with convenient syntax. Some of its arguments come from the “this” parameter. If the object is immutable and the method has no side-effects, it’s a pure function.

Converting a function to an immutable class with a method is a mechanical refactoring that I sometimes do, when the class has an intuitive name. The code does the same thing.

No partial application and currying are not both ways of partially applying a function. Partial application is a way of partially applying a function.

I have to concur with grandparent and also with user https://news.ycombinator.com/user?id=whilenot-dev in a sibling subthread.

We can say that when a function is curried (i.e. prepared or converted to curried form) then it supports partial application without any further transformation. In fact it happens naturally whenever the function is invoked.

E.g. if we have (lambda (x y z) (+ x y z)) converted into the curried form (lambda (x) (lambda (y) (lambda (z) (+ x y z)))), then while we do not yet have partial application, we can then partially apply just by passing arguments.

That is to say, we are partially applying in the abstract sense; if we pretend we still have a (lambda (x y z) ...) in our abstract semantics, then when we pass a value for x to the curried function, we then have effectively partially applied this abstract function, resulting in something that needs just the (y z) arguments now.

Languages that support implicit partial application erase the difference between f x y and (f x) y. That is to say, the programmer doesn't have to know whether f x y is a call two a function f with two arguments, or whether there is a partial application (f x) which binds the x argument, followed by an application of that resulting function to argument y.

Now if the language substrate is based on one-argument functions, under the hood, so that all functions with two or more arguments are implicitly transformed into one argument functions by currying, then partial application is "free", so to speak. The syntax may let you write f x y to call a function of two arguments, but the implementation is actually doing (f x) y.

Thus currying can support partial application in a similar way to how transformation of a program to CPS (continuation passing style) supports continuations. Partial application is "free" in a curried program similarly to how continuations are "free" in a CPSed program. Under CPS, you already have the return continuation as a hidden argument, so call/cc does nothing more than reveal what is hidden. Under currying, you already have a lambda that takes just one argument, and gives you a lambda that takes the next one.

I think when calling a curried function it isn't easy to differentiate between a simple function application and a partial (function) application. I would make the assumption that as long as a higher-order function is called, then what we're actually doing is a function transformation and thus a partial application - when we applied all arguments except the last one, then finally, when the last argument of a first-order function (= the partially applied higher-order function) is applied, then this function can not be transformed anymore and is simply just evaluated. I'm sure there's also a difference in lazy evaluated languages and others in there, but this is beyond my competence.

> Also, in any case, a constructed object is nothing like a partially applied function, so the parallel drawn is not useful.

Are you being serious? The fact that closures and objects are dual is a frequently made observation. It’s not something the poster invented and it’s not (usually) controversial.

Are you? Closures were not mentioned and are an implementation detail. In any case, an object and a bundle of closures being equivalent still has nothing to do with OP's talk of method calls being "easier to read and work[ing] better with autocomplete". Just read the original message upthread and try to make any useful meaning of it (especially in the context of turning add(1,2) into add 1 2).

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.

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 functools.partial etc.

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?

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

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

Neither of your examples does curry a function. The first one partially applies it (the Haskell way), the second one wraps the partial application in a redundant lambda (Haskell again). I think that's where the confusion is, let me also try to use the Haskell syntax...

This is an add function with two arguments:

  add :: (Int, Int) -> Int
  add (x, y) = x + y

At the moment it can not be partially applied, so let's curry it:

  -- addCurr :: Int -> Int -> Int
  addCurr = curry add

Now let's partially apply it for an increment function:

  -- increment :: Int -> Int
  increment = addCurr 1

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

You didn't curry it, you partially applied it. This was possible, because your function add was already curried.

Okay, that's a fair critique, let it not be said I can't admit when I'm wrong. I shouldn't have used `curry` as a verb there, as my point was about the concept of currying rather than the specific curry function.

My mistake there doesn't negate my larger point, but I've gotta go touch grass.

Coming back to this having spent a wonderful day outdoors.

Okay, writing this in Python because a) it's been a while since I wrote Haskell, b) it will let other readers read the code more easily, and c) Python clearly denotes what a partial is by having a `partial` function:

    from inspect import signature
    from functools import partial

    def curry(f, parameters=None):
        if parameters is None:
            parameters = list(signature(f).parameters.keys())

        if len(parameters) == 0:
            return f

        head = parameters[0]
        tail = parameters[1:]

        # I draw your attention to this line
        return lambda p: curry(partial(f, **{head: p}), tail)

    def divide(a, b, c):
        return a / b / c

    curried_divide = curry(divide)

    # prints "3"
    print(curried_divide(30)(5)(2)())

So... curry can be implemented in terms of partial applications, no?

I'm happy that you spent a wonderful day outdoors!

Do you think that makes your statement "Currying is a subset of partial application" (and doubling down on that) any more true?

After all, you can implement subtraction with just the help of addition and multiplication:

  add :: Int -> Int -> Int
  add a b = a + b

  mult :: Int -> Int -> Int
  mult a b = a * b

  sub :: Int -> Int -> Int
  sub a b = add a (mult (-1) b)

So, does that make "subtraction is a subset of addition" a true statement?

Yes. Why not? Would you be confused about what someone meant if they said that statement?

My critique of your original post is that you're treating English like it's a computer language where words mean very specific things. But the reality is that English is a cobbled-together bunch of words with imprecise meanings that arise from common usage. Let me reiterate: usage determines meaning, not the other way around.

You're approaching this conversation with your own preconceived notions about what the words mean and trying to force your preconceived notions onto everyone else instead of trying to understand what the other person means. It's a rude way to treat people trying to communicate with you.

I mean, it's clear that you understand the idea because you're coming up with examples that show that you understand it. Communication was successful. There's no problem with the communication. The problem is that you decided, after communication was successful, to force your preferred usage of the words on other people.

This is an extremely common interpersonal mistake that technical people make because unlike English, computer languages have very specific, objective meanings. But expecting that same objective specificity from humans speaking English isn't realistic, kind, or polite. It's one of the main reasons technical people are widely perceived as socially inept. Behaving like this hurts our careers, friendships, and romantic relationships. Doing this on HN is just a minor annoyance to everyone else, but if you do this in your life as a whole, the person you're harming most is yourself, because you're making it a pain in the ass to communicate with you.

I'm asking you to be a better reader and listener.

And look, maybe you can get skybrian or me to change the way we communicate to suit your preferences, but why? Nothing is gained. And if you spend your life trying to force people to communicate a certain way instead of trying to understand people, it's just going to be an endless war, where the only meaningful result you'll achieve is that it's harder for people to communicate with you. Is that what you want for yourself?

If you'd approached this from the perspective of "hey I think people would understand you better if you said it this other way", that would be fine. I think it's great to improve communication, and it's both up to speaker/writer and listener/reader to meet in the middle: both sides of this interaction can improve. But that's a pretty big difference between coming at someone like "you're wrong".

> Yes. Why not?

...because I think you'd write mathematical history if you can prove it?

> You're approaching this conversation with your own preconceived notions about what the words mean...

Peak meta, yes!

> ...to force your preferred usage of the words on other people.

Listen, currying is a defined term[0], as is partial application[1]. Those are primarily mathematic definitions, and your choice of words "...is a subset of..." is also stemming from a rather mathematical terminology if you'd ask me. Therefor its interpretation will primarily be itching logical intelligence.

Currying can be implemented by making use of a partial application, and partial application can be implemented by making use of currying a function. Neither one is a subset of the other and both are higher-order functions.

It was your choice of words with which you formed your statements, and no, I'm not going to discuss visual, linguistic, interpersonal, intrapersonal or naturalistic understandings with you on Hacker News about your intentions, I'm truly sorry. Your point "about the concept of currying" doesn't exist (yet AFAIK), feel free to imagine whatever higher concept you desire.

Even the confusion between currying and partial application is well known[2][3] and also documented on Wikipedia - you put in a prime example out of the confusion, thank you. You still double down on false statements, fine, use your languages however you want and feel free to interpret "I think you confuse currying with partial application." as a behavioral problem. It's truly amazing.

[0]: https://en.wikipedia.org/wiki/Currying

[1]: https://en.wikipedia.org/wiki/Partial_application

[2]: http://lambda-the-ultimate.org/node/2266

[3]: https://www.uncarved.com/articles/not-currying/

> ...because I think you'd write mathematical history if you can prove it?

No, because this is an informal conversation not a mathematical paper.

Clearly you understand what is meant if someone says that subtraction is a subset of addition. You also clearly understand they're not saying it as a statement of proof.

If you can understand someone well enough to correct their usage of words, you understand them well enough that they communicated successfully. So why create a problem?

> Listen, currying is a defined term[0], as is partial application[1]. Those are primarily mathematic definitions, and your choice of words "...is a subset of..." is also stemming from a rather mathematical terminology if you'd ask me. Therefor its interpretation will primarily be itching logical intelligence.

Yes, I'm well aware, I just don't care. People use words outside their dictionary definitions all the time and if we understand it, it doesn't matter.

Perhaps you should look up the word pedant? Dictionary authors are well aware of the pitfalls of relying on definitions as prescription rather than description.

> I'm not going to discuss visual, linguistic, interpersonal, intrapersonal or naturalistic understandings with you on Hacker News about your intentions,

Well, that's your prerogative, but I'll note that you haven't said anything interesting about currying because you keep assuming your audience knows less than they do. Learning to listen at an adult level would help you to have more interesting technical discussions, too.

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

It does not appear to me that skybrian is first learning about currying and partial application, and I'm not first learning about currying or partial application in this thread either.

Your play at humility that you didn't understand currying and partial application in the past kinda falls flat if you then go on to less-humbly assume that everyone else in the conversation is stuck where you once were.

You seem to be reacting to your own assumption that the original response was making an assumption.

I understood it instead to be generalizing to a related concept, and inferred no condescension, FWIW.

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.

I don't really understand the distinction between "multi-arity" and "unary" functions. In my mental model, all functions are unary, it's just that in "traditional", non-FP languages it's more common to pack arguments into tuples. That is `(a, b, c) => ...` in JS is a unary function which takes a tuple of 3 items. But the thing is, FP has tuples too (and in Haskell, with pretty much the same syntax), it's just that most of the time arguments aren't packed into tuples.

So could you elaborate to me where the distinction lies here and why is there a need to "simulate" things?

Say you are dealing with a callback mechanism that takes a function and (only) one value to pass:

   function c(f, v) { ... f(v) ... }

But what you actually need this callback mechanism to call is a function that takes two arguments. No default values.

    function f2(a, b) { ... }

There's no way in js that c is going to call f2 and set its b parameter to something. You can't set v to be a tuple so b will be filled:

    c(f2, "value") => b will be undefined.

    c(f2, [1, 2]) => a will be set to [1, 2].

you need to wrap f2 for this when calling c:

    function wrapf2(b) { return f2("fixed a", b) }

Or you can make c deconstruct v, or use apply:

    function c(f, v) { ... f(...v) ...  }
    function c(f, v) { ... f.apply(null, v) ...  }

but then v always needs to be an array:

    c(f, [1])
    c(f, [1, 2])

    c(f, 1) // fails

This is why in Javascript, multi-arity is different from unary with tuples. JS doesn't have tuples as a primitive / first-class type anyway. In some math notations we don't make the difference, but in most programming languages there's a distinction. Your model where functions are always unary but can take tuples, and (v) is the same as v, is correct (and useful when the distinction doesn't matter and is just annoying to deal with), but doesn't match the way many programming languages actually work. I believe even in most functional programming languages, (v) is different from v, you also said it.

In assembly, different parameters are in fully separate registers or stack entries. Interestingly, you could imagine representing tuples as C structs (that can have only one member) and always pass structs, and passing a one-member struct will actually have the exact same effect as passing a value of a primitive type.

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.

You can think of them as equivalent ways to write the same code. There are mechanical rewrites to go from one to the other, and these rewrites work in any direction. Which way is more readable depends on circumstances.

When a function needs a lot of parameters to do a calculation, these parameters can be arbitrarily grouped into records and supplied in any order. Languages have convenient syntaxes for certain ways of grouping parameters together.

For example, a closure creates a group of parameters in the form of a function.

Currying wraps, partial application unwraps.

> Currying is a subset of partial application

No, it isn't; it's a different operation.

Currying refers to building (effectively) functions of multiple arguments out of only one argument functions (such as in a language that has only those).

A curried function is not understood to have been applied, partially or otherwise; none of its arguments have been bound to values, thereby reducing its arity.

Partial application is an operation that requires one or more arguments. Currying does not require arguments; rather, the result of currying requires arguments (all of them).

There is a sort of partial application (effectively) going on when the curried function is applied to the arguments, which has to be done one argument at a time through the chain. At each step, one more argument is bound, and fewer remain.

Reply on news.ycombinator.com