b is not in the scope of the function } # Define two variables a and b a <- 1 b <- 2 # Run the function and note that it knows both a and b. # For b it cannot find a local definition and hence # uses the definition of the higher level of scope. f() ## [1] 3.141593 ## [1] 2 # f() did not change the value of a in the environment that called f(): print(a) ## [1] 1
This illustrates that the scoping model in R is dynamical scoping. This means that when a variable is used, that R in the first place will try to find it in the local scope, if that fails, it goes a step up and continues to do so until R ends up at the root level or finds a definition.
dynamical scoping
Dynamic scoping is possible, because R is an interpreted language. If R would be compiled, then the compiler would have a hard time to create all possible memory allocations at the time of compilation.
To take this a step further we will study how the scoping within S3 objects works.1 The example below is provided by the R Core Team.
# Citation from the R documentation: # Copyright (C) 1997-8 The R Core Team open.account <- function(total) { list( deposit = function(amount) { if(amount <= ) stop(“Deposits must be positive!\n”) total <<- total + amount cat(amount,“deposited. Your balance is”, total, “\n\n”) }, withdraw = function(amount) { if(amount > total) stop(“You do not have that much money!\n”) total <<- total - amount cat(amount,“withdrawn. Your balance is”, total, “\n\n”) }, balance = function() { cat(“Your balance is”, total, “\n\n”) } ) } ross <- open.account(100) robert <- open.account(200) ross$withdraw(30) ## 30 withdrawn. Your balance is 70 ross$balance() ## Your balance is 70 robert$balance() ## Your balance is 200 ross$deposit(50) ## 50 deposited. Your balance is 120 ross$balance() ## Your balance is 120 try(ross$withdraw(500)) # no way.. ## Error in ross$withdraw(500) : You do not have that much money!
This is a prime example of how flexible R is. At first this is quite bizarre, until we notice the <<- operator. This operator indicates that the definition of a level higher is to be used. Also the variable passed to the function automatically becomes an attribute of the object. Or maybe it was there because the object is actually defined as a function itself and that function got the parameter “amount” as a variable.
This example is best understood by realizing that this can also be written with a declared value “total” at the top level of our object.
While dynamical scoping has its advantages when working interactively, it makes code more confusing, and harder to read and maintain. It is best to be very clear with what is intended (if an object has an attribute, then declare it).Also never use variables of a higher level, rather pass them to your function as a parameter, then it is clear what is intended.)
In fact, a lot is going on in this short example and especially in the line total <<- total + amount. First, of all, open.account is defined as a function. That function has only one line of code in some sense. This is a fortiori the last line of code, and hence, this is what the function will return. So it will try to return a list of three functions: “deposit,” “withdraw” and “balance.”
What might be confusing in the way this example is constructed is probably is that when the function open.account is invoked, it will immediately execute the first function of that list. Well, that is not what happens. What happens is that the open.account object gets a variable total, because it is passed as an argument. So, it will exist within the scope of that function.
The odd thing is that rather than behaving as a function this construct behaves like a normal object that has an attribute amount and a creator function open.account(). This function in sets this attribute to be equal to the value passed to that function.
R will store variable definitions in its memory, and it may happen that you manage to read in a file for example, but then keep a mistake in your file. If you do not notice the mistake, it will go unnoticed (since your values are still there and you can work with them). The next person who tries to reproduce your code will fail. Start each file that contains your code with:
rm(list=ls()) # clear the environment
At this point, it is important to get a better understanding of the OO model implemented in R – or rather the multitude of models that are implemented in R.
Note
1 1 To fully appreciate what is going on here, it is best to read the section on the object models (Chapter 6 “The Implementation of OO” on page 87) in R first and more especially Section 6.2 “S3 Objects” on page 91.
♣6♣ The Implementation of OO
R is an object oriented (OO) language but if you know how objects work in for example C++, it might take some mental flexibility to get your mind around how it works in R. R is not a compiled language, and it is build with versatility in mind. In some sense most objects are a to be considered as an object and can readily be extended without much formalism and without recompiling.1
OO
object oriented
Personally, I find it useful to think of R as a functional language with odd object possibilities. This means that if you want to make some simple analysis, then you might skip this section. We did our best to keep the knowledge of OO to a minimum for the whole book.
Programming languages that provide support for object oriented programming, allow code to be data-centric as opposed to functional languages that are in essence logic-oriented. They do that by introducing the concept of a “class.” A manifestation of that class then becomes the object that we can work with. Objects represent real life things. For example, if we want to create a software that manages bank accounts, it might be possible to have one object that is the account, another that is the customer, etc.
The main idea is that in other parts of the code we can work with the object “account” and ask that object
