In R, function may not be as special as it is in other programming languages; it is regarded as one of the many types and can be passed as an argument to some other function. The way we deal with other objects such list and data.frame definitely applies to function. Here is a simple example in which we define two functions and pass them to another function as an argument, respectively.

add <- function(x,y,z) {
    x+y+z
}
product <- function(x,y,z) {
    x*y*z
}
aggregate <- function(x,y,z,fun) {
    fun(x,y,z)
}

In the example code above, we first define two functions called add and product respectively. Then we define another function called aggregate that tries to aggregate the three numeric vectors x, y, and z in some way specified by function fun. Here fun is assumed to be a function that takes three arguments as we call it in the body of aggregate. This treatment makes aggregate function more flexible in that it allows us to define the specific way in which we actually aggregate data.

To use aggregate function, we only need to call:

aggregate(1,2,3,product)

Therefore, aggregate in this example serves as a higher-order function because it is a function that takes a function as an argument.

In many situations, higher-order functions are shorter yet more expressive and implementation-neutral when a problem has diverse solutions but shares a common framework. For example, for-loop is an ordinary flow-control device that repeatedly does something but with a variable iterating along a vector.

Suppose we need to apply a function named f to each entry in a vector x. If the function in itself implemented to support vectorized operation, that is, it can directly take a vector as an argument, we may just call f(x) to do the job. However, not many functions directly support vectorized operations, nor do they need to in some circumstances. If we still want to proceed, a readily working solution is to use a for-loop.

result <- list()
for(i in seq_along(x)) {
    result[[i]] <- f(x[i])
}

In the code above, seq_along(x) produces a sequence from 1 to the length of x; 1:length(x) will do the same thing. The code looks simple and easy to implement, but it has some drawbacks in its design.

First, if the operation gets more complicated, it would be hard to read if we adopt a for-loop. Actually, the code tells R how to finish the task by a for-loop but does not tell us what the task is about. Trust me, when you take a look at very long loops, it would be a tough task to figure out what it is acutally doing.

Second, the for-loop relies on side effect. We say an operation has no side effect if it always yields the same output whenever it is given the same input. In this case, if you go through a vector and apply a function to each entry by a for-loop, you have to change the environment by introducing a iterating variable (e.g. i) and some others. In casual usage, it does no harm; but if you want to apply parallelism to the whole operation, side effects will be the roots of almost all bugs. That is because an operation with side effects depends not only on the input but also on the environment, which makes it too unpredictable to directly apply parallel computing correctly.

Note that R is a programming language that specializes in statistical computing. Its key advantage that sets it apart from other statistical software is its easiness to work with, its flexibility and extensibility. However, the correctness of code always beats simplicity, flexibility, extensibility and almost all other features. Unfortunately, the traditional techniques like for-loop relies on side effect, which is likely to not only reduce readability but also undermine the validity.

To tacle the problem, it is better to write R code that is easier for users to read rather than for the machine, and use higher-order functions that can be free from side-effects.

R provides a higher-order function called lapply which applies a function iteratively along a vector or a list, and yields a list containing the values.Using higher-order functions like lapply is just a good way to improve readability and correctness of the code. To demonstrate the point, here we show another simple example. The example implemented in for-loop can now be altered to using lapply.

result <- lapply(x, f)

It looks easy and elegant, doesn't it? lapply simpliy takes a vector or list as the first arugment, and a function as the second argument to apply to each entry. All results will be put into a new list and returned. If the function f needs more argument, you can still pass them by specifying more named arguments for lapply. For example, if add takes two argument, x and y, you can still pass the value of y in lapply.

add <- function(x,y) {
    x+y
}
result <- lapply(1:10, add, y=3)

Another way is to use closure. The code can be written like the following.

add <- function(y) {
    function(x) {
        x+y
    }
}
result <- lapply(1:10,add(3))

Here function add does not directly compute the value of x+y; instead, it computes a function that adds y to argument x. The anonymous function returned is called closure, which may be covered in more details in later posts.

If you want to get a numeric vector rather than a list, you can use sapply instead. It is the same with lapply except for that it simplifies the result by yielding a vector or a matrix.

result <- sapply(1:10,add(3))

In addition to lapply and sapply, R offers several more higher-order functions. apply calls a function to aggregate a certain dimension of a matrix. More common in other functional programming languages are Filter, Map, Reduce, Find, Position, and Negate. For more details on how we can use these higher-order functions, please read Common Higher-Order Functions in Functional Programming Languages in R documentation.

In R programming, I strongly recommend that you use higher-order functions to do most iterative tasks and better avoid using for-loops to minimize the unnecessary side effects that may reduce the performance and accountability of your code.