Functional peace of mind
RI think what I enjoy the most about functional programming is the peace of mind that comes with it.
With functional programming, there’s a lot of stuff you don’t need to think about. You can write
functions that are general enough so that they solve a variety of problems. For example, imagine
for a second that R does not have the sum()
function anymore. If you want to compute the sum of,
say, the first 100 integers, you could write a loop that would do that for you:
numbers = 0
for (i in 1:100){
numbers = numbers + i
}
print(numbers)
## [1] 5050
The problem with this approach, is that you cannot reuse any of the code there, even if you put it inside a function. For instance, what if you want to merge 4 datasets together? You would need something like this:
library(dplyr)
data(mtcars)
mtcars1 = mtcars %>%
mutate(id = "1")
mtcars2 = mtcars %>%
mutate(id = "2")
mtcars3 = mtcars %>%
mutate(id = "3")
mtcars4 = mtcars %>%
mutate(id = "4")
datasets = list(mtcars1, mtcars2, mtcars3, mtcars4)
temp = datasets[[1]]
for(i in 1:3){
temp = full_join(temp, datasets[[i+1]])
}
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
glimpse(temp)
## Observations: 128
## Variables: 12
## $ mpg <dbl> 21.0, 21.0, 22.8, 21.4, 18.7, 18.1, 14.3, 24.4, 22.8, 19....
## $ cyl <dbl> 6, 6, 4, 6, 8, 6, 8, 4, 4, 6, 6, 8, 8, 8, 8, 8, 8, 4, 4, ...
## $ disp <dbl> 160.0, 160.0, 108.0, 258.0, 360.0, 225.0, 360.0, 146.7, 1...
## $ hp <dbl> 110, 110, 93, 110, 175, 105, 245, 62, 95, 123, 123, 180, ...
## $ drat <dbl> 3.90, 3.90, 3.85, 3.08, 3.15, 2.76, 3.21, 3.69, 3.92, 3.9...
## $ wt <dbl> 2.620, 2.875, 2.320, 3.215, 3.440, 3.460, 3.570, 3.190, 3...
## $ qsec <dbl> 16.46, 17.02, 18.61, 19.44, 17.02, 20.22, 15.84, 20.00, 2...
## $ vs <dbl> 0, 0, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, ...
## $ am <dbl> 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, ...
## $ gear <dbl> 4, 4, 4, 3, 3, 3, 3, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 4, 4, ...
## $ carb <dbl> 4, 4, 1, 1, 2, 1, 4, 2, 2, 4, 4, 3, 3, 3, 4, 4, 4, 1, 2, ...
## $ id <chr> "1", "1", "1", "1", "1", "1", "1", "1", "1", "1", "1", "1...
Of course, the logic is very similar as before, but you need to think carefully about the structure holding your elements (which can be numbers, datasets, characters, etc…) as well as be careful about indexing correctly… and depending on the type of objects you are working on, you might need to tweak the code further.
How would a functional programming approach make this easier? Of course, you could use
purrr::reduce()
to solve these problems. However, since I assumed that sum()
does not exist,
I will also assume that purrr::reduce()
does not exist either and write my own, clumsy
implementation. Here’s the code:
my_reduce = function(a_list, a_func, init = NULL, ...){
if(is.null(init)){
init = `[[`(a_list, 1)
a_list = tail(a_list, -1)
}
car = `[[`(a_list, 1)
cdr = tail(a_list, -1)
init = a_func(init, car, ...)
if(length(cdr) != 0){
my_reduce(cdr, a_func, init, ...)
}
else {
init
}
}
This can look much more complicated than before, but the idea is quite simple; if you know about recursive functions (recursive functions are functions that call themselves). I won’t explain how the function works, because it is not the main point of the article (but if you’re curious, I encourage you to play around with it). The point is that now, I can do the following:
my_reduce(list(1,2,3,4,5), `+`)
## [1] 15
my_reduce(datasets, full_join) %>% glimpse
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
## Joining, by = c("mpg", "cyl", "disp", "hp", "drat", "wt", "qsec", "vs", "am", "gear", "carb", "id")
## Observations: 128
## Variables: 12
## $ mpg <dbl> 21.0, 21.0, 22.8, 21.4, 18.7, 18.1, 14.3, 24.4, 22.8, 19....
## $ cyl <dbl> 6, 6, 4, 6, 8, 6, 8, 4, 4, 6, 6, 8, 8, 8, 8, 8, 8, 4, 4, ...
## $ disp <dbl> 160.0, 160.0, 108.0, 258.0, 360.0, 225.0, 360.0, 146.7, 1...
## $ hp <dbl> 110, 110, 93, 110, 175, 105, 245, 62, 95, 123, 123, 180, ...
## $ drat <dbl> 3.90, 3.90, 3.85, 3.08, 3.15, 2.76, 3.21, 3.69, 3.92, 3.9...
## $ wt <dbl> 2.620, 2.875, 2.320, 3.215, 3.440, 3.460, 3.570, 3.190, 3...
## $ qsec <dbl> 16.46, 17.02, 18.61, 19.44, 17.02, 20.22, 15.84, 20.00, 2...
## $ vs <dbl> 0, 0, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, ...
## $ am <dbl> 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, ...
## $ gear <dbl> 4, 4, 4, 3, 3, 3, 3, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 4, 4, ...
## $ carb <dbl> 4, 4, 1, 1, 2, 1, 4, 2, 2, 4, 4, 3, 3, 3, 4, 4, 4, 1, 2, ...
## $ id <chr> "1", "1", "1", "1", "1", "1", "1", "1", "1", "1", "1", "1...
And if I need to merge another dataset, I don’t need to change anything at all. Plus, because my_reduce()
is very general, I can even use it for situation I didn’t write it for in the first place:
my_reduce(list("a", "b", "c", "d", "e"), paste)
## [1] "a b c d e"
Of course, paste()
is vectorized, so you could just as well do paste(1, 2, 3, 4, 5)
, but again, I want
to insist on the fact that writing or using such functions allows you to abstract over a lot of thing.
There is nothing specific to any type of object in my_reduce()
, whereas the loops have to be tailored
for the kind of object you’re working with. As long as the a_func
argument is a binary operator
that combines the elements inside a_list
, it’s going to work. And I don’t need to think about
indexing, about having temporary variables or thinking about the structure that will hold my
results.