Partial Application & Currying Comparison

[00:00:00]
>> Kyle Simpson: So you notice that we have the same outcome with curry, as we had with a partial application. We just got there in a decidedly different way. Same outcome, which is that I have a general function ajax, an intermediately more specific function called getCustomer, and an even more specific, getCurrentUser.

[00:00:19]
But with partial application, if you were to look a couple slides back, to get each level of the specialization, I had to call the utility again. With currying, I call it once at the beginning to set up my function, and then it automatically specializes itself as I pass info.

[00:00:40]
I think that's one of the reasons why currying is more attractive, is it ends up being that you write fewer calls to these utilities. You call it once to set up a function and you just automatically can specialize it. As a matter of fact, virtually all functional programming libraries that you will encounter.

[00:01:00]
All of the methods on those functional libraries are automatically already curried. Because it turns out, functional programmers want everything to be curried. And if you remember what I said at the very beginning when we were talking about shapes, one of the reasons why functional programmers like curried functions is because they like unitary functions.

[00:01:21]
Single input, another output, and you can see that a curried function is exactly that. It is a chain series of unitary functions. Single input single output, single input single output, single input single output.
>> Kyle Simpson: So in another words, to summarize this partial application versus currying thing, what we could say is that they are accomplishing the same thing, but doing it in a different way.

[00:01:51]
Both of them are specialization techniques, partial application is going to preset some of the arguments at the beginning. And then receive all the rest of them on the next call. And if you wanna do multiple steps of that specialization, you got to keep calling it, the utility. Currying on the other hand, doesn't preset any of the arguments.

[00:02:12]
And it receives each argument one at a time.
>> Kyle Simpson: If you ever get asked on a future job interview, what's the difference? What's partial application incurring? The answer is, both of them specialize, they do it differently. Partial application takes some input now, all the rest of the input later.

[00:02:32]
Currying takes no input now, each input one at a time.
>> Kyle Simpson: By the way, I wanna back up real quick one slide, skipped over one thing I didn't wanna skip over. There is this notion of what I would call, strict versus loose currying. And I'm calling this out because you're gonna encounter this and you may ask yourself.

[00:02:53]
This idea that I've been showing you recurring has been like we see online seven, which is that each time I call the function I provide only one input. Cuz that's how we did it when we manually curried, that's how it works in Haskell, you provide one input at a time.

[00:03:09]
I would call that the canonical or strict interpretation of currying. But if you had a function, say something that received five inputs, and you knew three of them right now, and you wanted to wait to define the other two. You can see there would be a little bit annoying to have to do three separate function calls with three separate parentheses.

[00:03:29]
It might be much more convenient, like line 10, to just be able to provide two inputs all in one call. You see where I'm coming from? So, that technique is what I would refer to as loose currying. Meaning, at each level of the function call, you can pass in one or more arguments.

[00:03:50]
And the function you get back is waiting for whatever the next arguments should be, you with me? The reason why it's important to point out loose currying is because, as far as I'm aware, every JavaScript functional programming library that I have seen does loose currying, not strict currying.

[00:04:11]
But if you're really trying to adhere to the true notion of what currying was, as it was conceived in Haskell, you'd be doing strict currying. I think the reason why those libraries chose the loose carrying form is for convenience only, not because it's the more, economically correct way of doing it.

[00:04:31]
So, just be aware when you see something like line 10 where multiple inputs are being passed, that still might be currying. It might just be loose currying instead.
>> Student: Why does partial application still exist in functional programming?
>> Kyle Simpson: That's a good question. So the question is, if currying is generally preferred, and you will find that it usually is, why even have a partial application?

[00:04:56]
The best answer I can give you, I mean, other than the fact that it's sort of historical and when something is in the economical body of work. It's never gonna get removed, other than that I would say, there are some cases where it'd be more convenient to do partial application than currying.

[00:05:13]
For example, let's say you have a function that starts out expecting five inputs. And you want to produce another function that expects three inputs, you wanna preset only two of them. If you were to curry it, two things would be true. First of all, you'd have to call it twice and that's a little annoying.

[00:05:31]
But secondly, the function you'd get back would not be a function that was expecting three inputs, it would be occurred function of three more chains. And that might not be the shape of function that you wanna pass around. So it might be the case that the partial application produces a more preferable shape, that's not gonna be common.

[00:05:52]
But that's why it might still exist is that, sometimes that tool might produce a function shape that is more preferable than a currying function.