An argument promise containing bytecode?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

An argument promise containing bytecode?

Taras Zakharko-3
Dear all,

I was playing around with some C code that inspects argument promises and I noticed that forwarded arguments sometimes contain bytecode in the PRCODE component. E.g. if I have a nested call like this:

  f <- function(x) x
  g <- function(x) f(x)

 g(1+1)

and inspect the value of “x” in g’s frame from within f’s frame (basically calling findVar(parent.frame(), x)), I would see a LANGSXP the first time g()  is invoked, but BCODESXP on every subsequent time.  Using PREXPR gets me the original LANGSXP in any case.

Now, this is curious behavior and I had a quick glance into R source code related to closure evaluation and argument matching, but I could not see anything that would generate bytecode for promises. Could someone with in-depth knowledge of R’s machinery explain what is going on?

Thanks,

Taras
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: An argument promise containing bytecode?

Simon Urbanek
Taras,

I don't think this has anything to do with promises, rather it is called Just-In-Time (JIT) compilation - see ?enablleJIT in R, it is enabled by default, so the function will be compiled on second use.

Cheers,
Simon



> On Mar 7, 2021, at 11:12 PM, Taras Zakharko <[hidden email]> wrote:
>
> Dear all,
>
> I was playing around with some C code that inspects argument promises and I noticed that forwarded arguments sometimes contain bytecode in the PRCODE component. E.g. if I have a nested call like this:
>
>  f <- function(x) x
>  g <- function(x) f(x)
>
> g(1+1)
>
> and inspect the value of “x” in g’s frame from within f’s frame (basically calling findVar(parent.frame(), x)), I would see a LANGSXP the first time g()  is invoked, but BCODESXP on every subsequent time.  Using PREXPR gets me the original LANGSXP in any case.
>
> Now, this is curious behavior and I had a quick glance into R source code related to closure evaluation and argument matching, but I could not see anything that would generate bytecode for promises. Could someone with in-depth knowledge of R’s machinery explain what is going on?
>
> Thanks,
>
> Taras
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: An argument promise containing bytecode?

Taras Zakharko-3
Thank you Simon! Such a trivial explanation… admittedly, I am a bit disappointed, I hoped there was more to the mystery :)

Best,

Taras

> On 8 Mar 2021, at 03:51, Simon Urbanek <[hidden email]> wrote:
>
> Taras,
>
> I don't think this has anything to do with promises, rather it is called Just-In-Time (JIT) compilation - see ?enablleJIT in R, it is enabled by default, so the function will be compiled on second use.
>
> Cheers,
> Simon
>
>
>
>> On Mar 7, 2021, at 11:12 PM, Taras Zakharko <[hidden email]> wrote:
>>
>> Dear all,
>>
>> I was playing around with some C code that inspects argument promises and I noticed that forwarded arguments sometimes contain bytecode in the PRCODE component. E.g. if I have a nested call like this:
>>
>> f <- function(x) x
>> g <- function(x) f(x)
>>
>> g(1+1)
>>
>> and inspect the value of “x” in g’s frame from within f’s frame (basically calling findVar(parent.frame(), x)), I would see a LANGSXP the first time g()  is invoked, but BCODESXP on every subsequent time.  Using PREXPR gets me the original LANGSXP in any case.
>>
>> Now, this is curious behavior and I had a quick glance into R source code related to closure evaluation and argument matching, but I could not see anything that would generate bytecode for promises. Could someone with in-depth knowledge of R’s machinery explain what is going on?
>>
>> Thanks,
>>
>> Taras
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel