From murdoch.duncan at gmail.com  Wed Apr 26 22:51:58 2017
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 26 Apr 2017 16:51:58 -0400
Subject: [Rd] byte-compiler bug
In-Reply-To: <3d1e32d7-1498-3fcc-6b46-1c5c20fe1f8b@fredhutch.org>
References: <3d1e32d7-1498-3fcc-6b46-1c5c20fe1f8b@fredhutch.org>
Message-ID: <7e22fc9d-6a51-bc24-b27b-1e0de300da0e@gmail.com>

On 26/04/2017 4:36 PM, Herv? Pag?s wrote:
> Hi,
>
> I'm running into a case where byte-compilation changes
> the semantic of a function. This is with R 3.4.0:
>
>    foo <- function(x) { TRUE && x }
>
>    foo(c(a=FALSE))
>    # [1] FALSE          # OK
>
>    foo(c(a=TRUE))
>    # [1] TRUE           # OK
>
>    foo(c(a=FALSE))
>    #     a              # ????
>    # FALSE
>
> The 3rd call returned a result that it different from the 1st
> call!

That does look like a bug.  Please file a bug report.

>
> After scratching my head for a while, I found out that there
> is a lot going on:
>
>    1) When calling foo the first 2 times, the function is not
>       byte-compiled so is behaving as expected.
>
>    2) However after the 2nd call, the function gets automatically
>       compiled. This seems to be a new feature in R 3.4.0 but
>       you'll have to grep the NEWS file to find out (search for
>       JIT).

The NEWS file is where we usually report news, so this isn't really that 
much of a surprise.  If you don't want to read it all at once, you can 
see it as it changes on the RSS feed at

http://developer.r-project.org/RSSfeeds.html


  The man page for cmpfun/enableJIT nicely explains
>       the JIT levels but I couldn't find anywhere that the level
>       is set to 3 by default. I don't even know how one is
>       supposed to get the current level. Calling enableJIT() to
>       change the level returns a value, and this value might
>       look like the previous level, but this is undocumented and
>       it returns 0 instead of 3 the 1st time I call it anyway.
>
>    3) There is some bug in the byte-compiler that seems to make it
>       treat `&&` like if it were `&` when compiling foo.

It's a bug, but that doesn't describe it completely.  TRUE & c(a=TRUE, 
b=FALSE) doesn't give the same thing as foo(c(a=TRUE, b=FALSE)).

Duncan Murdoch

>
> Cheers,
> H.
>
>  > sessionInfo()
> R version 3.4.0 (2017-04-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 16.04.2 LTS
>
> Matrix products: default
> BLAS: /home/biocbuild/bbs-3.5-bioc/R/lib/libRblas.so
> LAPACK: /home/biocbuild/bbs-3.5-bioc/R/lib/libRlapack.so
>
> locale:
>   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>   [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.0
>



[Rd] byte-compiler bug
Duncan Murdoch