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@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
