3 ms·

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], no

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 https://news.ycombinator.com/item?id=39959651

skybrian 3y ago
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.
- kazinator 3y ago
  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 https://news.ycombinator.com/user?id=whilenot-dev in a sibling subthread.
  - kazinator 3y ago
    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.
    - whilenot-dev 3y ago
      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.
      - deleted 3y ago
        [deleted]
gedbhrdvbhd 3y ago
> 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.
- ghusbands 3y ago
  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).

skybrian 3y ago

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.

kazinator 3y ago
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 https://news.ycombinator.com/user?id=whilenot-dev in a sibling subthread.
- kazinator 3y ago
  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.
  - whilenot-dev 3y ago
    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.
    - deleted 3y ago
      [deleted]

gedbhrdvbhd 3y ago

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

ghusbands 3y ago
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).