[R] strange things with eval and parent frames

[Mark.Bravington@csiro.au]

Dear mailing list,

I have found some strange behaviour which I think relates to parent frames
and eval. Can anyone explain what's going on here? 

First example:

> test.parent.funcs_ function() {
  outer.var_ 5
  subfunc1_ function() substitute( outer.var, envir=parent.frame())
  print( subfunc1())

  subfunc2b_ function() eval( quote( outer.var), envir=parent.frame())
  print( subfunc2b())
  
  subfunc2_ function() evalq( outer.var, envir=parent.frame()) 
  #print( subfunc2())
}

> test.parent.funcs()
[1] 5
[1] 5

If you try this without the hash before the 3rd print statement, it crashes,
complaining it can't find outer.var. But AFAICS, subfunc2 and subfunc2b
should return the same thing. So, at a minimum, evalq(...) doesn't seem to
be behaving the same as eval( quote(...)) as the documentation says it
should. But I think more fundamentally odd things are happening, as per
below.

Note BTW that this is NOT a classical scoping problem. Exactly the same
things happen if I define subfunc1 etc. outside the body of
test.parent.funcs.

Second example:
> test.parent.funcs2_ function() {
  subfunc3_ function() sys.call( -1)
  x_ subfunc3(); print( x)
  
  subfunc3a_ function() eval( quote( sys.call()), parent.frame())
  x_ subfunc3a(); print( x)
  
  subfunc3b_ function() evalq( sys.call(), parent.frame())
  x_ subfunc3b(); print( x)
}

> test.parent.funcs2()
test.parent.funcs2()
eval(expr, envir, enclos)
eval(expr, envir, enclos)

Hmmm. Again, I'd expect all three to do the same thing (have I
misunderstood?). What's even more odd, is that this time evalq and eval(
quote()) do coincide, but neither of them gives the answer I expected. I
thought that by doing the evaulation in the parent.frame, I could knock 1
level off the number of generations to go back in sys.call.

Why would anyone care? Well, the proximate reason for bothering to post this
is that I got very confused while using a debugger, which "manually"
evaluates expressions within the original frame (i.e. by calling eval). When
the functions I was debugging made calls to "parent.frame", everything went
very pear-shaped. However, I have a feeling that I've also hit this before
in another context. In the above cases, there happens to be a workaround,
but it's somewhat due to luck.

Some light can be shed on this by including some calls to sys.parents in the
sub-functions, but it's not easy to summarize the results. My best shot at a
short, comprehensible description is as follows. An environment can appear
several times in the list of active frames, albeit with different frame
numbers and different "parent frame numbers" each time. The environment is
IDENTICAL in each case-- you can get this from lapply( sys.frames(),
print)-- but it has a different "alias" (i.e. frame number each time).
Calling "sys.parent" seems to return the nominal parent of the LATEST
incarnation in the frame list. 

My suggestion (a hunch) is that everything would actually work fine if,
instead, sys.parent checked for the FIRST incarnation of the current frame,
and took the parent of that-- at least as a default option.

Incidentally, is there any way of testing whether two environments are
identical (e.g. between elements of the list returned by sys.frames())? The
operator == doesn't work, and nor does "all.equal". The only fudge I could
devise, was to print them via a textConnection, and compare the text
representations... ugh.

Can anyone shed any light on this?

cheers
Mark

*******************************

Mark Bravington
CSIRO (CMIS)
PO Box 1538
Castray Esplanade
Hobart
TAS 7001

phone (61) 3 6232 5118
fax (61) 3 6232 5012
Mark.Bravington at csiro.au 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._