When people first encounter currying or partial application in R, they often make a very specific mistake: they assume that R functions are "curried by default," similar to how they work in languages like Haskell or F#. You'll see students try to "freeze" an argument by calling the function with only some of its parameters, expecting R to hand them back a new, specialized function.

"Wait, why isn't this returning a function?"

Let's look at a concrete example. Imagine you're building a tool to calculate sales tax for different regions. You've written a straightforward function that takes a tax rate and a price:

calculate_tax <- function(rate, price) {
  return(price * rate)
}

Now, you realize you're doing a lot of calculations for New York (8.875%). To save yourself some typing, you might try this:

# This is the common mistake
ny_tax <- calculate_tax(0.08875) 
# You expect ny_tax to be a function you can call later with a price...
# But R throws an error: "argument 'price' is missing, with no default"

Here is the reality: in R, if you call a function, it executes immediately. It doesn't "wait" for the remaining arguments by returning a function; it just fails because the required price argument is missing. R functions are not curried by default.

Using Closures for Partial Application

If you want to create a specialized version of a function—which is what partial application actually is—you have to explicitly wrap that function inside another function. This creates a "closure," where the inner function remembers the environment (and the variables) of the outer function.

Here is how I actually handle this in my own production code when I want to avoid external dependencies:

make_tax_calculator <- function(rate) {
  function(price) {
    calculate_tax(rate, price)
  }
}

# Now we 'partially apply' the rate
ny_tax <- make_tax_calculator(0.08875)
ca_tax <- make_tax_calculator(0.0725)

# Now these behave like specialized functions
ny_tax(100) # Returns 8.875
ca_tax(100) # Returns 7.25

I find this approach incredibly useful when you're working with lapply or purrr::map. Instead of writing a messy anonymous function inside your loop, you can create a clean, named partial function beforehand.

True Currying: The Chain of Singles

Currying is slightly different from partial application. While partial application is about fixing *some* arguments, currying is the process of transforming a function that takes N arguments into a chain of N functions that each take exactly one argument.

It looks a bit academic, but it's a powerful pattern for building flexible pipelines. In R, it looks like this:

curried_add <- function(a) {
  function(b) {
    function(c) {
      a + b + c
    }
  }
}

# To get the result, you chain the calls
result <- curried_add(10)(20)(30) # Returns 60

You won't do this every day in R, but understanding it allows you to use functional programming libraries more effectively. For instance, if you use the purrr package, the partial() function does exactly what our make_tax_calculator did, but in a more generic way that works for any function.

📋 Practical Task

Building a Specialized Temperature Converter

You are working on a climate data project. You have a general function that converts temperatures based on a provided offset and a multiplier:

convert_temp <- function(multiplier, offset, temp) {
  return((temp * multiplier) + offset)
}

Your task is to use the concept of partial application to create two specialized functions using the convert_temp logic:

• celsius_to_fahrenheit: This should fix the multiplier at 1.8 and the offset at 32.
• celsius_to_kelvin: This should fix the multiplier at 1 and the offset at 273.15.

Once you have created these two functions, test them by passing the value 25 (Celsius) into both. Your celsius_to_fahrenheit function should return 77, and your celsius_to_kelvin function should return 298.15.