Portée et fonctions dans R 2.11.1: Qu'est-ce qui ne va pas?

Question

Cette question provient d'une gamme d'autres questions qui traitent essentiellement du même problème. Pour une raison étrange, l'utilisation d'une fonction dans une autre fonction échoue parfois dans le sens où les variables définies dans l'environnement local de la première fonction ne sont pas retrouvées dans la seconde fonction.

Le schéma classique en pseudo-code:

ff <- function(x){ 
    y <- some_value 
    some_function(y) 
} 
ff(x) 

Erreur dans eval (expr, Envir, Enclos): objet 'y' non trouvé

D'abord, je pensais qu'il avait quelque chose à voir avec les méthodes S4 et la portée, mais cela arrive aussi avec d'autres fonctions. J'ai eu une interaction avec l'équipe de développement de R, mais tout ce qu'ils ont fait, c'est de me diriger vers le site de rapport de bogue (ce qui n'est pas le plus invitant, je dois dire). Je n'ai jamais eu de commentaires. Comme le problème ne cesse de se poser, je me demande s'il y a une explication logique à cela. Est-ce une erreur commune dans tous ces cas, et si oui, laquelle? Ou est-ce vraiment un bug?

Certaines de ces questions:

• Using functions and environments
• R (statistical) scoping error using transformBy(), part of the doBy package.
• How to use acast (reshape2) within a function in R?
• Why can't I pass a dataset to a function?
• Values not being copied to the next local environment

PS: Je sais que le R-devel liste, au cas où vous vous demanderiez ...

Answer 1

Comme Dirk l'a mentionné dans sa réponse, il n'y a pas réellement de problème avec le code que vous avez posté. Dans les liens que vous avez publiés dans la question, il semble y avoir un thème commun: some_function contient du code qui dérange avec les environnements d'une certaine manière.Cette Messing est explicite, en utilisant new.env et with ou implicitement, en utilisant un argument data, qui a probablement une ligne comme

y <- eval(substitute(y), data) 

La morale de l'histoire est double. Tout d'abord, essayez d'éviter de manipuler explicitement les environnements, sauf si vous êtes vraiment sûr de savoir ce que vous faites. Et deuxièmement, si une fonction a un argument de données, placez toutes les variables dont vous avez besoin dans cette trame de données.

Answer 2

Il ya sans aucun doute des bogues dans R, mais beaucoup de problèmes que les gens ont eu sont souvent des erreurs dans l'implémentation de some_function, pas de R lui-même. R a des règles de portée (voir http://cran.r-project.org/doc/manuals/R-intro.html#Scope) qui, lorsqu'elles sont combinées avec l'évaluation paresseuse des arguments de la fonction et la capacité à eval arguments dans d'autres portées sont extrêmement puissantes mais entraînent souvent des erreurs subtiles.

Answer 3

Eh bien il n'y a pas de problème dans ce que vous avez publié:

/tmp$ cat joris.r 
#!/usr/bin/r -t 

some_function <- function(y) y^2 

ff <- function(x){ 
    y <- 4 
    some_function(y) # so we expect 16 
} 
print(ff(3))   # 3 is ignored 
$ ./joris.r 
[1] 16 
/tmp$ 

Pourriez-vous retraiter et Postan bug réel ou disfonctionnement?

Answer 4

R a une portée lexicale et dynamique. La portée lexicale fonctionne automatiquement, mais la portée dynamique doit être implémentée manuellement et nécessite une bonne tenue des livres. Seules les fonctions utilisées de manière interactive pour l'analyse des données ont besoin d'une portée dynamique, de sorte que la plupart des auteurs (comme moi!) N'apprennent pas à le faire correctement. Voir aussi: standard non-standard evaluation rules