Currying vs Partial Application

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

Recently I have come across some really interesting questions and debates around these two terms and how they differ from one another. There seems to be widespread confusions with many examples demonstrates one whilst intends another, and some simply uses the terms interchangeably.

Whilst admittedly not being a function programming expert, I’ve spent a bit of time scouring the web for information from those who are and I think I’ve finally come to understand the difference between the two!

In case you’re not familiar with what Currying and Partial Application means, here’s some quick definitions for you.



According to Wikipedia, currying is:

the technique of transforming a function that takes multiple arguments in such a way that it can be called as a chain of functions each with a single argument.

This means for a given function f, which takes three parameters x, y, and z and returns R:

f(x, y, z) => R

once curried it becomes:

curriedf(x) => g(y) => h(z) => R

When you supply x to the curried function curriedf, you get back a new function g, g takes a single parameter and returns another function h which also takes a single parameter but this time returns R.

So to get the full application of the original function f, you need to call


With currying, parameters must be supplied from left to right starting from the left-most parameter.

Partial Application

Again, borrowing from Wikipedia, Partial applications refers to:

the process of fixing a number of arguments to a function, producing another function of smaller arity.

This means for a given function f, which takes three parameters x, y, and z and returns R:

f(x, y, z) => R

If you fix the first parameter x to 1 then you get another function g that takes two parameters and returns R:

g(y, z) => R    <=>    f(1, y, z) => R

Equally if you fix both x and y to values 1 and 2 respectively then you get another function h that takes one parameter and returns R:

h(z) => R    <=>    f(1, 2, z) => R

Currying vs Partial Application

At first glance the similarities are hard to miss, and one might be tempted to suggest (well, many have!) that they are two of the same thing or that one is simply a special case of the other. However, there are some crucial differences between the two which ultimately dictates their very different applications in practice.

imageTo help you understand the differences, try and ignore the fact that both Currying and Partial Application takes a function and returns a function with less input parameters and instead think about the function that’s returned (see image):


– when you curry a function F, you get back a chain of functions that returns another function at every stage, except the last function in the chain

– you still have to apply all the necessary parameters if you want to get the full application of the original function (i.e. R)

– you have to supply parameters one at a time to a chain of functions

– you have to supply parameters from left to right in the same order as the original function F

Partial Application

– when you partially apply a function F, you get back a function that allows you to get the full application (i.e. R) of the original function F with less parameters

– you don’t have to supply parameters in any particular order


So, the main difference between currying and partial application lies in the return type of the new function produced, let’s see how they differentiate in practice with a simple example in Javascript:

// original function that takes three parameters a1, a2 and a3
function f(a1, a2, a3) {
    return a1 + a2 + a3;

// curried function which takes one parameter at a time
function curry(a1) {
    // each stage takes another parameter and get you closer to the
    // full application of f
    return function (a2) {
        // but only with the inner most function do you actually get
        // the return value you wanted
        return function (a3) {
            return f(a1, a2, a3);

// partial applied function which takes one parameter and fixes
// the other 2
function partial(a1) {
    // a partially applied function of the original function f can
    // get you the full application straight away
    return f(a1, 5, 10);


curry(1)(5)(10); // returns 16
partial(1); // returns 16

Parting thoughts…

In general, both techniques produce reusable, helpful functions which fixes some parameters of the original function. For example, with Currying the function returned at each and every stage of the chain can be reused and potentially create a tree of functions:


though in practice I can think of few examples where you would require such level of reusable functions…

I’m of the opinion that Partial Application has greater applications (not pun intended!) in solving real world problems. In fact, using Partial Application is something we’ve all done before – e.g. take a general purpose function which needs lots of parameters and make a more high level function out of it by fixing some parameters with sensible defaults:

// base method which provides a way to encapsulate common logic, but
// needs a number of parameters in order to 'tune' its behaviour
// NOTE: this C# code won't compile, it's just to illustrate a common
// pattern of using partial application
public void DoFileIoOperation(
    FileReadWriteMode mode,
    string path, string content,
    FileOverwriteMode overwriteMode)

// high level methods more useful to anyone who's trying to get things done
public void DoFileRead(string path)
        FileReadWriteMode.Read, path, null, FileOverwriteMode.None);

public void DoFileWrite(string path, string content)
        FileReadWriteMode.Write, path, content, FileOverwriteMode.Overwrite);

Also, the fact that you don’t need to supply each and every parameters one at a time, in a particular order makes Partial Application easier to apply in practice. As much as one would love to stay ‘pure’, it’s simply far more pragmatic to repackage the original function signature and fix multiple parameters in one go!

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!