For those coming to R from other languages, it seems very odd that R users import code from packages the way that they do. For instance, if you are used to Python, this is the general pattern of “using code from elsewhere”:

import math import numpy as np from random import randint # Usage: math . floor ( 3.2 ) np . array ( ... ) randint ()

Meanwhile, in R, you’re likely to see

library ( dplyr ) data_frame ( x = 1 , y = "A" ) %>% mutate ( z = TRUE )

… with the subtext being that users must simply know that the data_frame() , mutate() , and %>% functions are actually all from the dplyr package. Why is R so unusual here?

Unlike C or some familiar Lisps, R has proper namespace support, so it’s not as though conflicting symbols are simply overwritten when you use library() in the way they would be when using #include in C. Moreover, there is one place that R users do work with a highly granular mechanism to control how symbols are imported into an environment: when working with the NAMESPACE file included with every R package. If you crack open one of these files, you’ll see lines like

importFrom(dplyr, mutate, data_frame, %>%)

which look a bit like pseudo-R code. Yet there is no importFrom() function in R itself. It’s not hard to write one if we make use of the not-widely-advertised namespace API, either:

importFrom <- function ( pkg , ... ) { pkg <- as.character ( substitute ( pkg )) call <- match.call () symbols <- vapply ( 3 : length ( call ), function ( i ) { as.character ( call[[i]] ) }, character ( 1 )) ns <- loadNamespace ( pkg ) importIntoEnv ( parent.frame (), symbols , ns , symbols ) invisible ( NULL ) } # Confirm that it works: importFrom ( tibble , is.tibble , as_tibble ) df <- dplyr :: data_frame ( x = 1 , y = "A" ) is.tibble ( df ) #> [1] TRUE is.tibble #> function(x) { #> "tbl_df" %in% class(x) #> } #> <bytecode: 0x55c14454ca60> #> <environment: namespace:tibble>

So that’s clearly not the barrier. In fact if this appeals to you there is a fully-realized vision of an import*() function for R available in the import package. But there is still a question of why the language itself does not include such a function.

I was curious about whether anything had been written about this before, so I asked about the historical reason that R does not have an importFrom() function on the r-devel mailing list. While I didn’t get an answer from those involved, those who did comment raised some interesting points.

The first is that larger R programs tend to get refactored into R packages, which do have careful management of imported functions and packages. (This largely aligns with my own experience.) And the second is that R has a strong culture of development-by-interpreter, where library() is a useful shortcut to getting the third-party functions that you want.

I also suspect that the history of the language plays a part as well. When namespace support was added to the R language in 2003, the language had a strong emphasis on maintaining compatibility with the S language, so that new users would not need to rewrite much of their existing code. S used library() , and thus R provided library() . And insofar as there was a design principle for the S language, it was that users could begin using it without thinking of themselves as “programmers”, and gradually slide into programming as their analyses demanded it. The library() approach is in line with this philosophy, in my view.

And of course, there is also the reality that R has almost thirty years of development and design decisions to account for – almost 50 if we include its S ancestors dating back to 1976. By this measure, R is contemporary with the very first versions of Unix (1975), Emacs (1976), and TeX (1978). I’m sure that some of these decisions might be regretted or resented by the core R developers, but most of these now-features have users expecting at least some semblance of backwards compatibility.

In the end I think that the main reason that we don’t see mass migration to solutions like the import package speaks to a deeper division in the R community. The R users who are likely to raise concerns over using library() in scripts – those worried about code hygiene or dependency management, for example – are likely willing and able to solve these problems in other ways, notably by refactoring code into packages. And as Roger Peng argued in his recent keynote at useR! 2018, R has focused on programmer-oriented features at its peril.