One of the features of R that I've been working with lately (thanks R.cache) is the ability of functions to declare other functions. In particular, when one does this, one is able to have some variables be an inherent part of the resulting function.
For example:
functionBuilder <- function(wordToSay) {
function() {
print(wordToSay)
}
}
Can build a function like so:
functionToRun <- functionBuilder("hello nested world")
Then functionToRun() will result in "hello nested world". But if you just look at functionToRun (i.e., print it), you will see code that matches functionBuilder. What you will also see is that functionToRun has an environment. How can one access the value of wordToSay that is stored inside of functionToRun?
At first I tried:
get("wordToSay",env=functionToRun)
... but functionToRun isn't an environment and can't be transformed into an environment via as.environment. Similarly, because functionToRun isn't an environment, you can't attach to it or use with.
I found that environment was the accessor function to get and set environments, in an analgous way to how names gets and sets name attributes. Therefore, the code to get functionToRun's environment is environment(functionToRun) and therefore, we can access wordToSay with the line get("wordToSay",environment(functionToRun)).
Related
I would like to set a functions argument as the variable name of a global variable defined within a function.
The reason is to create a general function which, connects to a database downloads data into a global variable with the argument of the function as its name.
This would allow to connect to a database once, download data, store them in a variable with a defined name and use it outside of the function. (Alternatively I am also open for different approaches)
test=function(name_argument){
substitute(name_argument)<<-2
}
test("name")
name->2 | The global variable should be callable with the variable name
I have tried using assign(), substitute(), eval() in various forms, without any success.
Does anyone a) know a solution to this and b) can describe the logic behind it. (For example why does substitute seemingly not work with global variables)
I'm just getting my feet wet in R and was surprised to see that a function doesn't modify an object, at least it seems that's the default. For example, I wrote a function just to stick an asterisk on one label in a table; it works inside the function but the table itself is not changed. (I'm coming mainly from Ruby)
So, what is the normal, accepted way to use functions to change objects in R? How would I add an asterisk to the table title?
Replace the whole object: myTable = title.asterisk(myTable)
Use a work-around to call by reference (as described, for example, in Call by reference in R by TszKin Julian?
Use some structure other than a function? An object method?
The reason you're having trouble is the fact that you are passing the object into the local namespace of the function. This is one of the great / terrible things about R: it allows implicit variable declarations and then implements supercedence as the namespaces become deeper.
This is affecting you because a function creates a new namespace within the current namespace. The object 'myTable' was, I assume, originally created in the global namespace, but when it is passed into the function 'title.asterisk' a new function-local namespace now has an object with the same properties. This works like so:
title.asterisk <- function(myTable){ do some stuff to 'myTable' }
In this case, the function 'title.asterisk' does not make any changes to the global object 'myTable'. Instead, a local object is created with the same name, so the local object supercedes the global object. If we call the function title.asterisk(myTable) in this way, the function makes changes only to the local variable.
There are two direct ways to modify the global object (and many indirect ways).
Option 1: The first, as you mention, is to have the function return the object and overwrite the global object, like so:
title.asterisk <- function(myTable){
do some stuff to 'myTable'
return(myTable)
}
myTable <- title.asterisk(myTable)
This is okay, but you are still making your code a little difficult to understand, since there are really two different 'myTable' objects, one global and one local to the function. A lot of coders clear this up by adding a period '.' in front of variable arguments, like so:
title.asterisk <- function(.myTable){
do some stuff to '.myTable'
return(.myTable)
}
myTable <- title.asterisk(myTable)
Okay, now we have a visual cue that the two variables are different. This is good, because we don't want to rely on invisible things like namespace supercedence when we're trying to debug our code later. It just makes things harder than they have to be.
Option 2: You could just modify the object from within the function. This is the better option when you want to do destructive edits to an object and don't want memory inflation. If you are doing destructive edits, you don't need to save an original copy. Also, if your object is suitably large, you don't want to be copying it when you don't have to. To make edits to a global namespace object, simply don't pass it into or declare it from within the function.
title.asterisk <- function(){ do some stuff to 'myTable' }
Now we are making direct edits to the object 'myTable' from within the function. The fact that we aren't passing the object makes our function look to higher levels of namespace to try and resolve the variable name. Lo, and behold, it finds a 'myTable' object higher up! The code in the function makes the changes to the object.
A note to consider: I hate debugging. I mean I really hate debugging. This means a few things for me in R:
I wrap almost everything in a function. As I write my code, as soon as I get a piece working, I wrap it in a function and set it aside. I make heavy use of the '.' prefix for all my function arguments and use no prefix for anything that is native to the namespace it exists in.
I try not to modify global objects from within functions. I don't like where this leads. If an object needs to be modified, I modify it from within the function that declared it. This often means I have layers of functions calling functions, but it makes my work both modular and easy to understand.
I comment all of my code, explaining what each line or block is intended to do. It may seem a bit unrelated, but I find that these three things go together for me. Once you start wrapping coding in functions, you will find yourself wanting to reuse more of your old code. That's where good commenting comes in. For me, it's a necessary piece.
The two paradigms are replacing the whole object, as you indicate, or writing 'replacement' functions such as
`updt<-` <- function(x, ..., value) {
## x is the object to be manipulated, value the object to be assigned
x$lbl <- paste0(x$lbl, value)
x
}
with
> d <- data.frame(x=1:5, lbl=letters[1:5])
> d
x lbl
1 1 a
2 2 b
3 3 c
> updt(d) <- "*"
> d
x lbl
1 1 a*
2 2 b*
3 3 c*
This is the behavior of, for instance, $<- -- in-place update the element accessed by $. Here is a related question. One could think of replacement functions as syntactic sugar for
updt1 <- function(x, ..., value) {
x$lbl <- paste0(x$lbl, value)
x
}
d <- updt1(d, value="*")
but the label 'syntactic sugar' doesn't really do justice, in my mind, to the central paradigm that is involved. It is enabling convenient in-place updates, which is different from the copy-on-change illusion that R usually maintains, and it is really the 'R' way of updating objects (rather than using ?ReferenceClasses, for instance, which have more of the feel of other languages but will surprise R users expecting copy-on-change semantics).
For anybody in the future looking for a simple way (do not know if it is the more appropriate one) to get this solved:
Inside the function create the object to temporally save the modified version of the one you want to change. Use deparse(substitute()) to get the name of the variable that has been passed to the function argument and then use assign() to overwrite your object. You will need to use envir = parent.frame() inside assign() to let your object be defined in the environment outside the function.
(MyTable <- 1:10)
[1] 1 2 3 4 5 6 7 8 9 10
title.asterisk <- function(table) {
tmp.table <- paste0(table, "*")
name <- deparse(substitute(table))
assign(name, tmp.table, envir = parent.frame())
}
(title.asterisk(MyTable))
[1] "1*" "2*" "3*" "4*" "5*" "6*" "7*" "8*" "9*" "10*"
Using parentheses when defining an object is a little more efficient (and to me, better looking) than defining then printing.
Programmers often uses multiple small functions inside of larger functions. Along the way we may want to collect things in an environment for later reference. We could create an environment with new.env(hash=FALSE) and pass that along to the smaller functions and assign with assign. Well and dandy. I was wondering if we could use the reference id of the environment and not pass it along to the child functions but still assign to the environment by reference the environment id.
So here I make
myenv <- new.env(hash=FALSE)
## <environment: 0x00000000588cc918>
And as typical could assign like this if I passed along to the child functions the environment.
assign("elem1", 35, myenv)
myenv[["elem1"]]
# 35
What I want is to make the environment in the parent function and pass the reference id along instead so I want to do something like:
assign("elem2", 123, "0x00000000588cc918")
But predictably results in:
## Error in as.environment(pos) :
## no item called "0x00000000588cc918" on the search list
Is it possible to pass along just the environment id and use that instead? This seems cleaner than passing the environment from function to function and returning as a list and then operating on the environment in that list...and maybe more memory efficient too.
I would want to also access this environment by reference as well.
Environments are not like lists. Passing an environment to a function does not copy its contents even if the contents of the environment are modified within the function so you don't have to worry about inefficiency. Also, when an environment is passed to a function which modifies its contents the contents are preserved even after the function completes so unlike the situation with lists there is no need to pass the environment back.
For example, the code below passes environment e to function f and f modifies the contents of it but does not pass it back. After f completes the caller sees the change.
f <- function(x, env) {
env$X <- x
TRUE
}
e <- new.env()
f(1, e)
## [1] TRUE
e$X
## [1] 1
More about enviorments in Hadely's book: http://adv-r.had.co.nz/Environments.html
I am still struggling with R scoping and environments. I would like to be able to construct simple helper functions that get called from my 'main' functions that can directly reference all the variables within those main functions - but I don't want to have to define the helper functions within each of my main functions.
helpFunction<-function(){
#can I add a line here to alter the environment of this helper function to that of the calling function?
return(importantVar1+1)
}
mainFunction<-function(importantVar1){
return(helpFunction())
}
mainFunction(importantVar1=3) #so this should output 4
If you declare each of your functions to be used with dynamic scoping at the beginning of mainfunction as shown in the example below it will work. Using helpFunction defined in the question:
mainfunction <- function(importantVar1) {
# declare each of your functions to be used with dynamic scoping like this:
environment(helpFunction) <- environment()
helpFunction()
}
mainfunction(importantVar1=3)
The source of the helper functions themselves does not need to be modified.
By the way you might want to look into Reference Classes or the proto package since it seems as if you are trying to do object oriented programming through the back door.
Well, a function cannot change it's default environment, but you can use eval to run code in a different environment. I'm not sure this exactly qualifies as elegant, but this should work:
helpFunction<-function(){
eval(quote(importantVar1+1), parent.frame())
}
mainFunction<-function(importantVar1){
return(helpFunction())
}
mainFunction(importantVar1=3)
The R way would be passing function arguments:
helpFunction<-function(x){
#you can also use importantVar1 as argument name instead of x
#it will be local to this helper function, but since you pass the value
#it will have the same value as in the main function
x+1
}
mainFunction<-function(importantVar1){
helpFunction(importantVar1)
}
mainFunction(importantVar1=3)
#[1] 4
Edit since you claim it "doesn't work":
helpFunction<-function(importantVar1){
importantVar1+1
}
mainFunction<-function(importantVar1){
helpFunction(importantVar1)
}
mainFunction(importantVar1=3)
#[1] 4
I'd like to remove all the objects from my current environment except two of them, something like this
rm(list=setdiff(ls(),c("current_object_a","current_object_b")))
but I'd like to call it within a function. If I do it now, nothing happens because I'm deleting the environment variables inside the function, not the global environment.
You have to specify the environment to both ls and rm.
rm(list = setdiff(ls(globalenv()),
c("current_object_a", "current_object_b")),
pos = globalenv())
But, really, why do you want to do this? Deleting things out of the global environment from within a function seems like a Bad Thing.
You can specify the environment with either the pos or envir argument
rm(list=setdiff(ls(pos=globalenv()),
c("current_object_a","current_object_b")),
pos=globalenv())
From ?rm
The ‘pos’ argument can specify the environment from which to
remove the objects in any of several ways: as an integer (the
position in the ‘search’ list); as the character string name of an
element in the search list; or as an ‘environment’ (including
using ‘sys.frame’ to access the currently active function calls).
The ‘envir’ argument is an alternative way to specify an
environment, but is primarily there for back compatibility.