From luke-tierney at uiowa.edu  Fri Nov 11 21:36:48 2016
From: luke-tierney at uiowa.edu (luke-tierney at uiowa.edu)
Date: Fri, 11 Nov 2016 14:36:48 -0600
Subject: [Rd] Frames in compiled functions
In-Reply-To: <CAFOpNVHo4xwVayMdwQ+srM80L1ckEh=yiQSLaYOVA0vb2pU8mg@mail.gmail.com>
References: <1209438475.1993878.1478891603236.ref@mail.yahoo.com>
	<1209438475.1993878.1478891603236@mail.yahoo.com>
	<CAFOpNVHo4xwVayMdwQ+srM80L1ckEh=yiQSLaYOVA0vb2pU8mg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1611111435210.2513@luke-Latitude>

That's about it. The plan is to modify the interpreter to do the same
so the inconsistency will go away. Code that is affected by this is
making assumptions that it should not.

Best,

luke

On Fri, 11 Nov 2016, Winston Chang wrote:

> 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]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] Frames in compiled functions
luke-tierney at uiowa.edu