Skip to content

Can a function know what other function called it?

9 messages · Robert Gentleman, Kynn Jones, Duncan Murdoch +1 more

#
Suppose function foo calls function bar.  Is there any way in which
bar can find out the name of the function that called it, "foo"?

There are two generalization to this question that interest me.
First, can this query go farther up the call stack?  I.e. if bar now
calls baz, can baz find out the name of the function that called the
function that called it, i.e. "foo"?  Second, what other information,
beside its name, can bar find about the environment where it was
called?  E.g. can it find out the file name and line number of the
function call?

Thanks!
#
Hi Kynn,
Kynn Jones wrote:
essentially yes. You can find out about the call stack by using sys.calls and
sys.parents etc. The man page plus additional manuals should be sufficient, but
let us know if there are things that are not clear.
yes - you can (at least currently) get access to the entire calling stack and
some manipulations can be performed.
there is no real concept of file and line number associated with a function
definition (nor need their even be a name - functions can be anonymous).

 If you want to map back to source files then I think that currently we do not
keep quite enough information when a function is sourced. Others may be able to
elaborate more (or correct my mistakes).  I think we currently store the actual
text for the body of the function so that it can be used for printing, but we
don't store a file name/location/line number or anything of that sort. It could
probably be added, but would be a lot of work, so it would need someone who
really wanted it to do that.

 However, you can find out lots of other things if you want.  Do note that while
 it is possible to determine which function initiated the call, it is not
necessarily possible to figure out which of the calls (if there is more than one
in the body of the function) is active.  R does not keep track of things in that
way. To be clear if foo looks like:

  foo <- function(x) {
    bar(x)
    x = sqrt(x)
    bar(x)
  }
  and you have a breakpoint in bar, you could not (easily) distinguish which of
the two calls to bar was active. There is no line counter or anything of that
sort available.

 best wishes
   Robert

  
    
#
On Sat, May 23, 2009 at 4:55 PM, Robert Gentleman <rgentlem at fhcrc.org> wrote:
Thanks a lot!  That was very helpful.

This is the best I was able to come up with:

bar <- function() {
  caller <- sub("\\(.*", "", rev(sys.calls())[[2]])
  cat(sprintf("bar: i was called by \"%s\"\n", caller))
}

foo <- function() bar()
bar: i was called by "foo"
So it works, but I'm a n00b with R.  If there's a less labored way to
achieve this, please let me know.

And thanks again for your response.  It was very instructive.

KJ
#
On 23/05/2009 4:55 PM, Robert Gentleman wrote:
By default we don't store either a copy of the source or the references 
to the source file for functions in a package, but those options can be 
enabled, and are enabled by default for users working at the console. 
For example, with this source in c:/temp/test.R:

g <- function(x) {
   x <- 1
   y <- 4
}

You can do the following:

 > getOption("keep.source")
[1] TRUE
 > source("c:/temp/test.R")
 > as.list(g)[[2]]
{
     x <- 1
     y <- 4
}
attr(,"srcfile")
c:/temp/test.R

You can also find out which part of the file corresponds to each 
statement of the function definition.  For example,

 > attributes(as.list(g)[[2]])
$srcref
$srcref[[1]]
{

$srcref[[2]]
x <- 1

$srcref[[3]]
y <- 4


$srcfile
c:/temp/test.R

 > print(attr(as.list(g)[[2]], "srcref")[[2]])
x <- 1
 > print(attr(as.list(g)[[2]], "srcref")[[2]], useSource=FALSE)
<srcref: file "c:/temp/test.R" chars 2:3 to 2:8>
The evaluator doesn't pay any attention to srcref records, so this is 
still true, but it would be possible to keep the srcref on the stack as 
well as all the other info there.

I've written code (and I think I sent it to you last year) that can do 
things like replacing the statement coming from a particular line of a 
file with whatever code you like; this could be used in writing a nice 
source-level debugger.

Duncan Murdoch
#
Duncan Murdoch wrote:
[snip]
Please
yes

  
    
2 days later
#
On 5/24/2009 10:23 AM, Romain Francois wrote:
Here's a patch file that does this.  (Will it make it through to the 
mailing list?  We'll see.)  It's still in progress, so I'm not even 
ready to put it into R-devel, but you're welcome to try it out.

The basic idea is that it attaches srcref attributes to the values 
returned from sys.calls (which won't be displayed, but if you want to 
play with them you can) and to .Traceback (which traceback() will 
display).  debug() will also show them.

Not sure what bad side effects (e.g. on execution time) this has.

Duncan Murdoch
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: srcref.patch
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20090526/252500d2/attachment.pl>
#
Duncan Murdoch wrote:
Many thanks. I'll play with this right now. My guess is that since these 
"srcref" records are calculated anyway by the parser, this won't affect 
too much the execution time.

  
    
#
On 5/26/2009 12:57 PM, Romain Francois wrote:
It does add a little extra execution time to every statement, and more 
to lines that have source references.  Whether enough to matter, I don't 
know.

Duncan Murdoch
#
On 5/26/2009 12:57 PM, Romain Francois wrote:
I have now committed a more complete version of the code to R-devel. 
It's still "experimental"; formats of the displays are likely to change, 
and the internal structures might.

This is likely to disrupt front-ends that expect a particular format 
from tracebacks or the debugger; hopefully the added information will 
make up for the inconvenience.

Duncan Murdoch