Nested future_map / map generates warning on ..1 argument

[Ilia-Kosenkov]

Consider these examples:

1. Works as expected

library(purrr)
library(furrr)
#> Loading required package: future
map(1:2, ~map_int(6:7, ~.x))
#> [[1]]
#> [1] 6 7
#> 
#> [[2]]
#> [1] 6 7

^{Created on 2018-11-19 by the reprex package (v0.2.1.9000)}
2. Works as expected

library(purrr)
library(furrr)
#> Loading required package: future
future_map(1:2, ~map_int(6:7, ~.x))
#> [[1]]
#> [1] 6 7
#> 
#> [[2]]
#> [1] 6 7

^{Created on 2018-11-19 by the reprex package (v0.2.1.9000)}
3. But this one throws a warning

library(purrr)
library(furrr)
#> Loading required package: future
future_map(1:2, ~map_int(6:7, ~..1))
#> Warning: <anonymous>: ..1 may be used in an incorrect context
#> [[1]]
#> [1] 6 7
#> 
#> [[2]]
#> [1] 6 7

^{Created on 2018-11-19 by the reprex package (v0.2.1.9000)}
4. And standard purrr does not

library(purrr)
library(furrr)
#> Loading required package: future
map(1:2, ~map_int(6:7, ~..1))
#> [[1]]
#> [1] 6 7
#> 
#> [[2]]
#> [1] 6 7

^{Created on 2018-11-19 by the reprex package (v0.2.1.9000)}

I believe it is worth making future_map consistent with map providing that a user understands to what exactly ..1 is evaluated in a nested map scenario.

[DavisVaughan]

This warning happens deep in the stack of globals and even lower into the codetools package. It might be a bug, I'll try and ask over in globals if there is a fix for it.

For my reference, it happens deep in findGlobalsAndPackages() when walking over the code. Specifically there is a call to w$leaf(v, w) with v = ..1. Apparently isDDSym(v) is TRUE, which triggers a call to w$isLocal("...", w) which is FALSE which signals the warning.

isDDSym() seems to explicitly look for that kind of ..1 symbol, so I feel like thats probably right. But maybe w$isLocal("...", w) is doing the wrong thing.

[kaji331]

I get similar issue but an error not warning: my code like

require(tibble)
require(furrr)
require(magrittr)
plan("multiprocess",workers=4,gc=T)

enframe(list) %$% future_map2(1:length(name),value,function(x,y) {
require(purrr)
y %>% split(.$cluster) %>% map(~unique(.x$gene))
})

Error: Failed to retrieve the result of MulticoreFuture () from the forked worker (on localhost; PID 12549). Post-mortem diagnostic: No process exists with this PID, i.e. the forked localhost worker is no longer alive.

[DavisVaughan]

I've confirmed that this is the same as HenrikBengtsson/future#402 so I'm closing in favor of that