[Rd] Frames in compiled functions

[Winston Chang]

It looks like the byte compiler is optimizing local() to an
immediately-invoked function, instead of using eval() and substitute(). I
don't know if that's exactly how it's implemented internally, but that's
what it looks like here:

compiler::enableJIT(0)

fun <- function(x) {
   local(sys.calls())
}
fun(1)
## [[1]]
## fun(1)
##
## [[2]]
## local(sys.calls())
##
## [[3]]
## eval.parent(substitute(eval(quote(expr), envir)))
##
## [[4]]
## eval(expr, p)
##
## [[5]]
## eval(expr, envir, enclos)
## call
## [[6]]
## eval(quote(sys.calls()), new.env())
##
## [[7]]
## eval(expr, envir, enclos)


compiler::cmpfun(fun)(1)
## [[1]]
## (compiler::cmpfun(fun))(1)
##
## [[2]]
## (function() sys.calls())()


-Winston


On Fri, Nov 11, 2016 at 1:13 PM, brodie gaslam via R-devel <
r-devel at r-project.org> wrote:

> I noticed some problems that cropped in the latest versions of R-devel
> (2016-11-08 r71639 in my case) for one of my packages.  I _think_ I have
> narrowed it down to the changes to what gets byte-compiled by default.  The
> following example run illustrates the problem I'm having:
>
>   compiler::enableJIT(0)
>   fun <- function(x) local(as.list(parent.frame(2)))
>   fun(1)
>   ## $x
>   ## [1] 1
>   ##
>
>
>
>   compiler::cmpfun(fun)(1)
>   ## <contents of .GlobalEnv>
>
>
> Is this considered problematic at all?  If so, might it make sense to
> broaden the list of functions that disable JIT compilation beyond
> `browser`?  I'm pretty sure I can work around this issue in my specific use
> case, but figured it is worth mentioning here since it is a change in
> behavior.
>
>
> Regards,
>
> B.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]