So let me preface this by stating that I found a better, cleaner way around this problem. But this is one of those situations where I'm left slightly determined to figure out what I was trying to do.
trace_back() allows you to access call information and other information through your call stack:
fun1 <- function() {
fun2()
}
fun2 <- function() {
trc <<- rlang::trace_back()
}
fun1()
str(trc)
#> List of 4
#> $ calls :List of 2
#> ..$ : language global::fun1()
#> ..$ : language global::fun2()
#> .. ..- attr(*, "srcref")= 'srcref' int [1:8] 2 3 2 8 3 8 2 2
#> .. .. ..- attr(*, "srcfile")=Classes 'srcfilecopy', 'srcfile' <environment: 0x563740a1d5f0>
#> $ parents: int [1:2] 0 1
#> $ ids : chr [1:2] "0x563740e0f840" "0x563740e0f798"
#> $ indices: int [1:2] 36 37
#> - attr(*, "class")= chr "rlang_trace"
Created on 2020-06-04 by the reprex package (v0.3.0)
The ids binding contains the environment IDs. I had a peculiar situation where I had an object in one level of the call stack that I wanted to access - but I couldn't find a clear route to access that environment from the function I was writing in (they were in parallel environments that bother inherited from global).
The rlang::trace_back() call shows me the byte codes of the environments from each level of the call stack. So that begs the question - if I have the byte code of an environment (as a string), can I access that environment using that string?
I acknowledge that this is not a "should do" - but is this a "can do"? I know it would be pretty horrible practice to try to grab objects using a memory address. But is there a way that you can co it using any current tools in R? Or is this something that you'd need to hop under the hood and use C++?