On: Guido was right, there should be no lambda in Pyth...

[ColFrancis]

> l_add needs the arguments passed one at a time. We never see this syntax with multiple parenthesis in Python. It works and it has many benefits built in, but it would be a paradigm shift to expect pythonistas to start writing their programs this way, it’s just not Pythonic.

He makes a big point about currying in his particular manner, but what's wrong with

    f = lambda x,y: x+y
    g = lambda y: f(3,y)

That's also currying right? I've always been a little confused as to why the style he advocates is necessarily better. I'm not a functional guy so I'm maybe I'm missing something, what is the benefit of syntactic sugar for partial application to the first (or last) argument of a function? What if I want partial application of a function with the middle argument specified? Now you're out of luck and have to do the above anyway.

ETA: on the main point

> In Python, we do not use lambda with the intention of using lambda calculus. Our syntax needs to encode our intention in the places we have used it, and where we will use it. These use cases are inline, anonymous functions.

That seems needlessly nitpicking. Wikipedia has "lambda function" as a synonym for anonymous function so it seems pretty widespread in our language at this point. https://en.wikipedia.org/wiki/Anonymous_function

[Jtsummers → ColFrancis]

Not quite, that is partial application. Actual currying would allow you to do partial application this way, making it less explicit:

  > g = f(3) # no second parameter provided
  g = <unary function> # however it would be indicated in the python shell

To get it in Python you'd need to do this:

  f = lambda x: lambda y: x + y
  g = f(3) # result is a function, or funcallable, or whatever Python calls the resultant type

This makes the currying explicit. In general, currying is taking an n-ary function and reducing it to a series of n unary functions. These three are equivalent, in Haskell(ish, rusty):

  f x y = x + y
  g x = \y -> x + y
  h = \x -> \y -> x + y

In Haskell, you don't have to use the explicit form of `h` (or the explicit form in the Python example) if you don't want to (and it would probably be weird if you used it extensively).

[thaumasiotes → Jtsummers]

> Actual currying would allow you to do partial application this way, making it less explicit

> To get it in Python you'd need to do this:

> f = lambda x: lambda y: x + y

> This makes the currying explicit. In general, currying is taking an n-ary function and reducing it to a series of n unary functions.

Something's gone wrong; your example of explicit currying conflicts with your definition of currying. `f` is a unary function.

[Jtsummers → thaumasiotes]

The original `f` was a binary function:

  f = lambda x, y: x + y

My updated curried `f` is a unary function, but it returns a unary function itself:

  f = lambda x: lambda y: x + y

That's what currying is. I just reused the name, if you prefer:

  curried_f = lambda x: lambda y: x + y

EDIT:

And note, it makes the partial application less explicit/verbose than the original, but the currying is very explicit because of Python's syntax.

  g = curried_f(3)

Is "just" a function call, while:

  g = lambda y: f(3, x)

does the same thing (functionally, at least) but the partial application is made explicit.

[dragonwriter → ColFrancis]

> That's also currying right?

No, currying is the transformation that takes a function f such that f(x0, x1, ... xn) = r and returns a function f' such that f'(x0)(x1)... (xn) = r.

Haskell doesn’t really have currying so much as having only one argument functions and a syntax for defining them that means one way to define a function that works like the result of currying a multiargument function looks a lot like defining a multiargument function in other languages.

[dllthomas → dragonwriter]

From another (probably less helpful but neat!) perspective, currying is turning x^(y*z) into (x^y)^z

[jcparkyn → ColFrancis]

I'm no FP expert, but I would call that partial application and not currying.

[MadcapJake → ColFrancis]

Currying is partial application for free on all function parameters in the order they were declared. It makes partial application no-hassle if you are supplying successive arguments in each application.

[ColFrancis → MadcapJake]

I know this is a very late reply, but I'm curious. How often does it align that the functional argument that you want to specify is in the correct position of the argument list that you get to make use of this feature? The times that I need to partially apply are slim, and I don't believe it's consistent that they're on the same side all the time.

The lambda keyword is long which makes it a pain, but currying really is equivalent to specialised partial application right? People seem to love currying so much I feel like I don't understand something here.

For context I work a lot with java, R, and Python which all have anonymous functions and higher order functions, but are all decidedly _not_ "functional languages".