Isso é causado por um bug na forma como lobstridentifica o ambiente

MrFlick apontou nos comentários que x |> lapply(function(x) obj_addr(x))retorna a resposta certa e x |> lapply(obj_addr)retorna a errada. Isso indica que algo estranho está acontecendo com os ambientes. A questão é se isso é causado por lobstr::obj_addr()ou lapply(). Acontece que isso decorre da maneira como lobstrusa rlang, o que faz com que ele procure o objeto no ambiente incorreto.

O que faz lobstr::obj_addr()?

A fonte (ligeiramente simplificada) é a seguinte:

obj_addr <- function(x) {
  x <- enquo(x)
  obj_addr_(quo_get_expr(x), quo_get_env(x))
}

obj_addr_()é a função workhorse escrita em C que obtém o endereço de memória. No entanto, primeiro o R obj_addr()usa as rlang ferramentas quosure como uma forma de acessar o objeto sem aumentar a contagem de referências . Isso permite que a coleta de lixo aconteça corretamente mais tarde, garantindo que não haja referências ao objeto por aí. No entanto, no caso de lapply(x, lobstr::obj_addr), ele não acessa corretamente o ambiente dos elementos de x, que é onde o erro surge.

O que acontece com os ambientes em lapply()?

Considere a seguinte função para obter o ambiente de um objeto do qual uma função é chamada:

f <- function(x) {
    rlang::quo_get_env(rlang::enquo(x))
}

Podemos chamar isso de lapply()ambas as maneiras:

x <- list(a = 1, b = 2, c = 3)

lapply(x, \(y) f(y)) # anonymous function
# $a
# <environment: 0x557c265eb438>

# $b
# <environment: 0x557c265ea910>

# $c
# <environment: 0x557c26e275c8>

lapply(x, f) # function provided directly
# $a
# <environment: R_EmptyEnv>

# $b
# <environment: R_EmptyEnv>

# $c
# <environment: R_EmptyEnv>

O primeiro conjunto de resultados faz sentido. lapply()cria um ambiente temporário cada vez que chama a função anônima (o fechamento da função).

No entanto, não faz sentido que lapply(x, f)esteja sendo executado no ambiente vazio. Sabemos que podemos nos referir a objetos no ambiente global com lapply(). Mas o ambiente vazio por definição não contém objetos e não tem pai:

f_parent <- function(x) {
    e <- rlang::quo_get_env(enquo(x))
    message("Objects in environment: ", length(ls(e)))
    message("Parent environment: ", parent.env(e))
}

lapply(x, f_parent)
# Objects in environment: 0
# Error in parent.env(e) : the empty environment has no parent

Então rlang::quo_get_env(rlang::enquo(x))claramente retorna o ambiente errado. Vamos tentar encontrar o ambiente pai da função chamada usando o lapply()R base:

f2 <- function(x) {
    parent.env(environment())
}
lapply(x, f2)
# $a
# <environment: R_GlobalEnv>

# $b
# <environment: R_GlobalEnv>

# $c
# <environment: R_GlobalEnv>

Isso faz mais sentido e nos dá uma pista sobre o que está acontecendo.

Escrevendo nossa própria função para obter o ponteiro

Para descartar lapply()como fonte dessa inconsistência, vamos escrever nossa própria versão de lobstr::obj_addr()que não mexe com ambientes. A linha relevante da obj_addr_()função de nível C é onde ela converte o SEXPpara um ponteiro:

static_cast<void *>(x);

Aqui está uma função semelhante para obter o ponteiro que ignora o rlangconteúdo:

get_pointer <- inline::cfunction(
    sig = c(x = "integer"),
    body = '
    // cast SEXP to a void pointer like lobstr
    void* ptr = (void*) x;

    // put the pointer in a character array
    char addr_chr[32];
    snprintf(addr_chr, sizeof(addr_chr), "%p", ptr);

    // put address in character vector and return it
    SEXP addr = PROTECT(allocVector(STRSXP, 1));
    SET_STRING_ELT(addr, 0, mkChar(addr_chr));
    UNPROTECT(1);
    return addr;',
    includes = "#include <stdio.h>"
)

Comparando get_pointer()comlobstr::obj_addr()

Vamos definir xe verificar os endereços individualmente:

x <- list(a = 1, b = 2, c = 3)

lobstr::obj_addr(x[[1]]) # [1] "0x557c22e8eb28"
lobstr::obj_addr(x[[2]]) # [1] "0x557c22e8eb60"
lobstr::obj_addr(x[[3]]) # [1] "0x557c22e8eb98"

Agora podemos comparar os resultados usando lobstrde três maneiras. Usarei sapply()em vez de lapply()pois imprime melhor. Podemos ver que sapply(x, lobstr::obj_addr)não está correto.

lobstr::obj_addrs(x) # correct
# [1] "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, \(y) lobstr::obj_addr(y)) # correct
#                a                b                c
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, lobstr::obj_addr) # incorrect
#                a                b                c
# "0x557c24fdd7a0" "0x557c24fdd8f0" "0x557c24fdda78"

A questão é se podemos obter os resultados corretos se pularmos as coisas do ambiente. É aqui que podemos usar get_pointer():

sapply(x, \(y) get_pointer(y)) # correct
#                a                b                c 
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, get_pointer) # correct
#                a                b                c 
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

Então get_pointer()obtém os resultados corretos nas duas vezes. Isso indica que o problema está no lobstruso de ferramentas de quosure do rlang. Na verdade, não tenho certeza se isso é um rlangproblema ou se o problema é como lobstrestá usando rlang. No entanto, como ambos os pacotes são parte do r-lib , imagino que um relatório de bug arquivado em qualquer um deles encontraria seu caminho para o lugar certo bem rápido.

Parece que esse comportamento se deve ao fato de que obj_addrestá enquoing seu argumento antes de recuperar seu endereço (veja a definição da função). Então, podemos examinar o comportamento de enquoseparadamente da parte real de recuperação de endereço.

Para verificação, podemos definir uma função baseada em obj_addrque recupera o endereço como:

.internal.address = function(.) lobstr:::obj_addr_(rlang::quo_get_expr(.), 
                                                   rlang::quo_get_env(.))

Para referência, o objeto aestá localizado em:

.Internal(inspect(a))
#@58398aa88108 13 INTSXP g1c0 [MARK,REF(65535)]  1 : 10 (expanded)

Quando fora do corpo de um fechamento, enquoretorna algo inútil para recuperar o endereço do objeto, pois enquoparece ser capaz de avaliar um símbolo completamente (em contraste com, substitutepor exemplo) e retornar um objeto recém-construído:

enquo(a)
#<quosure>
#expr: ^<int: 1L, 2L, 3L, 4L, 5L, ...>
#env:  empty
.internal.address(enquo(a))
#[1] "0x5839a29c0018"
.internal.address(enquo(a))
#[1] "0x5839a29c0088"

Dentro de um fechamento, porém, tudo funciona como esperado:

f1 = function(x) enquo(x)
f1(a)
#<quosure>
#expr: ^a
#env:  global
.internal.address(f1(a))
#[1] "0x58398aa88108"
.internal.address(f1(a))
#[1] "0x58398aa88108"

lapplyavalia seus argumentos durante a construção da chamada e, provavelmente, podemos simular seu comportamento com force(para deixar claro) assim:

force1 = function(x) { force(x); enquo(x)}
force1(a)
#<quosure>
#expr: ^<int: 1L, 2L, 3L, 4L, 5L, ...>
#env:  empty
.internal.address(force1(a))
#[1] "0x5839a2816848"
.internal.address(force1(a))
#[1] "0x5839a2816b58"

já que enquonão retorna mais um símbolo pesquisável.

Como MrFlick observa nos comentários, envolver com outra camada de fechamento funciona como esperado, pois enquonão parece chegar a uma avaliação completa de seu argumento:

force2 = function(y) { force(y); f1(y)}
force2(a)
#<quosure>
#expr: ^y
#env:  0x58399eef63d8
.internal.address(force2(a))
#[1] "0x58398aa88108"

Além disso, por exemplo, se redefinirmos obj_addrao longo das linhas de:

obj_addr2 = function(x) lobstr:::obj_addr_(substitute(x), parent.frame())

então lapplynão causa confusão:

obj_addr(a)
#[1] "0x58398aa88108"
obj_addr2(a)
#[1] "0x58398aa88108"
lapply(list(a, b), obj_addr)
#[[1]]
#[1] "0x58399a991748"
#
#[[2]]
#[1] "0x58399a9917b8"

lapply(list(a, b), obj_addr2)
#[[1]]
#[1] "0x58398aa88108"
#
#[[2]]
#[1] "0x58398aa88108"