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

101–110 of 134 posts

Re: Currying

#101

Post by bheadmaster »

kerkeslager wrote: post #61
ReleaseCandidat wrote: post #59

Earlier quoted context omitted.

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

> 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 "curry…

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.

Re: Currying

#102

Post by whilenot-dev »

bheadmaster wrote: post #101
kerkeslager wrote: post #61

Earlier quoted context omitted.

> 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 "curry…

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…

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?

Re: Currying

#103

Post by RobMurray »

indigosun wrote: post #88

I recently saw the title, Learn Physics with Functional Programming, and thought to myself... I know physics and functional programming but I want to learn Haskell. Having gone through it, I highly recommend the book; especially to anyone knowledgeable about any 2 and interested in the third. I love Haskell. I love writing it, and reading it. Haskell is a beautiful programming language. One where I felt immediately a…

Wow what a lot of parentheses! To me the first example is perfectly clear because it follows the same precedence rules I learned for arithmetic at school, along with most programming languages. There's nothing special about Haskell here, in Python I would write:

    >>> math.sqrt(2) + 1 * 3 + 3 * 2 + 1 / 7  
    10.557070705230238
The only difference I see is the parentheses used for function application in python.

Re: Currying

#104

Post by gedbhrdvbhd »

ghusbands wrote: post #81
kerkeslager wrote: post #50

Earlier quoted context omitted.

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…

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

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

Re: Currying

#105

Post by epolanski »

zarzavat wrote: post #22
worddepress wrote: post #9

Earlier quoted context omitted.

In Haskell it is easy. If you "forget" the last argument to a function, you get returned a function where you can provide that later on. A bit like saying "you can fill this in later". That is a "curried" function. Example add 1 2 // add is curried, you can use it like this, the "normal" way, returns 3 p = add 1 // since add is curried I can also provide just the first argument p 2 // and then apply the last argument…

It’s worth noting that even in Haskell, overuse of the so called point-free style is disliked for much the same reasons: https://wiki.haskell.org/Pointfree There is a sliding scale and even at the Haskellers have a limit of how much point-free they can take. In JavaScript use of the style is problematic in another way: unlike Haskell in JS the length of the argument list is variable, which means that if someone adds…

All your JS/TS example says is that the `f` callback is not curried, so your point is entirely lost on me.

Re: Currying

#106

Post by epolanski »

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 can't figure out what you mean.

how is `add a b c = a + b + c` being curried an issue to you?

Re: Currying

#107

Post by ghusbands »

gedbhrdvbhd wrote: post #104
ghusbands wrote: post #81

Earlier quoted context omitted.

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

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

Re: Currying

#108

Post by mjarrett »

boxed wrote: post #62

Currying makes positional only parameters look cooler and fancier. It's a trap. Labeled arguments is the way to go for 99% of all parameters. Accidental currying is horrible.

One of my favorite features in OCaml is labeled arguments. You get a similar flavor of partial application, but without the strict argument order requirement (most of the time -- higher order functions are strict about labeled-function arguments).

Re: Currying

#109

Post by fs_tab »

boxed wrote: post #62

Currying makes positional only parameters look cooler and fancier. It's a trap. Labeled arguments is the way to go for 99% of all parameters. Accidental currying is horrible.

Somewhat related - be wary of implicit parameter passing in function pipelines. For example, Try ['10', '10', '10'].map(Number.parseInt) in your browser console. What's actually being called is:

Number.parseInt('10', 0) Number.parseInt('10', 1) Number.parseInt('10', 2)

Re: Currying

#110

Post by bheadmaster »

whilenot-dev wrote: post #102
bheadmaster wrote: post #101

Earlier quoted context omitted.

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…

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 
    #include 

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

    template 
    class Curry {
        std::function fn;
      public:
        Curry(std::function 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{uncurried};

        std::cout
Post reply on HN