Une fonction - formellement appelée fermeture dans la documentation R - comprend non seulement ses arguments et son corps, mais aussi son environnement. Ce dernier est constitué de la collection d'objets présents au moment de la création de la fonction. Une compréhension de la façon dont les environnements fonctionnent dans R est essentielle pour écrire des fonctions R efficaces.

1 L'environnement de premier niveau
Considérez cet exemple:

>w<-12
> f <- function(y) {
+ d <- 8
+ h <- function() {
+ return(d
*
(w+y))
+}
+ return(h())
+}
> environment(f)
<environment: R_GlobalEnv>

>w<-12
> f <- function(y) {
+ d <- 8
+ h <- function() {
+ return(d
*
(w+y))
+}
+ return(h())
+}
> environment(f)
<environment: R_GlobalEnv>

mo
[1] "f" "w"

mo
[1] "f" "w"

mo
[1] "f" "w"

mo
[1] "f" "w"

> ls.str()
f : function (y)
w : num 12

> ls.str()
f : function (y)
w : num 12

2 La hiérarchie de portée
Nous allons d'abord obtenir une vue d'ensemble intuitive de la façon dont fonctionne la portée dans R, puis la relier aux environnements.
Si nous travaillons avec le langage C, nous dirons que la variable w dans la section précédente est globale à f (), tandis que d est local à f (). Les choses sont similaires dans R, mais R est plus hiérarchique. En C, nous n'aurions pas de fonctions définies dans les fonctions, comme nous avons avec h () à l'intérieur de f () dans notre exemple. Cependant, puisque les fonctions sont des objets, il est possible - et parfois souhaitable du point de vue de l'objectif d'encapsulation de la programmation orientée objet - de définir une fonction dans une fonction; nous créons simplement un objet, que nous pouvons faire n'importe où.
Ici, nous avons h () étant local à f (), tout comme d. Dans une telle situation, il est logique que la portée soit hiérarchique. Ainsi, R est établi de sorte que d, qui est local à f (), est à son tour global à h (). Il en est de même pour y, car les arguments sont considérés comme des sections locales dans R.
De même, la nature hiérarchique de la portée implique que puisque w est global à f (), elle est aussi globale à h (). En effet, nous utilisons w dans h ().
En termes d'environnements, alors, l'environnement de h () consiste en ce que les objets sont définis à l'instant h () existe; c'est-à-dire au moment où cette affectation est exécutée:

h <- function() {
}
return(d
*
(w+y))

h <- function() {
}
return(d
*
(w+y))

> f(2)
[1] 112

> f(2)
[1] 112

> f(2)
[1] 112

> f(2)
[1] 112

>h
Error: object 'h' not found

>h
Error: object 'h' not found

>f
function(y) {
}
d<-8
h <- function() {
return(d
*
(w+y))
}
print(environment(h))
return(h())
> f(2)
<environment: 0x875753c>
[1] 112

>f
function(y) {
}
d<-8
h <- function() {
return(d
*
(w+y))
}
print(environment(h))
return(h())
> f(2)
<environment: 0x875753c>
[1] 112

Comparez tout cela à la situation dans laquelle les fonctions ne sont pas imbriquées:

>f
function(y) {
}
d<-8
return(h())
>h
function() {
}
return(d
*
(w+y))

>f
function(y) {
}
d<-8
return(h())
>h
function() {
}
return(d
*
(w+y))

Le résultat est le suivant:

> f(5)
Error in h() : object 'd' not found

> f(5)
Error in h() : object 'd' not found

Cela ne fonctionne pas car d n'est plus dans l'environnement de h (), car h () est défini au niveau supérieur. Ainsi, une erreur est générée.
Pire, si, par hasard, il y avait eu une variable indépendante d dans l'environnement de niveau supérieur, nous n'obtenions pas de message d'erreur mais obtenions des résultats incorrects.
Vous pourriez vous demander pourquoi R ne s'est pas plaint de l'absence de y dans la définition alternative de h () dans l'exemple précédent. Comme mentionné précédemment,
R n'évalue pas une variable jusqu'à ce qu'elle en ait besoin dans le cadre d'une politique appelée évaluation paresseuse. Dans ce cas, R avait déjà rencontré une erreur avec d et n'a donc jamais atteint le point où il essaierait d'évaluer y.
Le correctif est de passer d et y comme arguments:

>f
function(y) {
d<-8
return(h(d,y))
}
>h
function(dee,yyy) {
return(dee
*
(w+yyy))
}
> f(2)
[1] 88

>f
function(y) {
d<-8
return(h(d,y))
}
>h
function(dee,yyy) {
return(dee
*
(w+yyy))
}
> f(2)
[1] 88

D'accord, regardons une dernière variation:

>f
function(y,ftn) {
d<-8
print(environment(ftn))
return(ftn(d,y))
}
>h
function(dee,yyy) {
}
return(dee
*
(w+yyy))
>w<-12
> f(3,h)
<environment: R_GlobalEnv>
[1] 120

>f
function(y,ftn) {
d<-8
print(environment(ftn))
return(ftn(d,y))
}
>h
function(dee,yyy) {
}
return(dee
*
(w+yyy))
>w<-12
> f(3,h)
<environment: R_GlobalEnv>
[1] 120

Lorsque f () est exécuté, l'argument formel ftn est apparié par l'argument réel h. Étant donné que les arguments sont traités comme des sections locales, vous pouvez supposer que ftn pourrait avoir un environnement différent du niveau supérieur. Mais comme discuté, un cloître inclut l'environnement, et ainsi ftn a l'environnement de h.
Notez bien que tous les exemples concernant les variables nonlocales concernent les lectures, pas les écritures. Le cas des écritures est crucial et sera traité dans la section 7.8.1.

3 Plus d'informations sur ls ()
Sans arguments, un appel à ls () à partir d'une fonction renvoie les noms des variables locales en cours (y compris les arguments). Avec l'argumentation de l'environnement, il imprimera les noms des locaux de n'importe quelle trame de la chaîne d'appel.

>f
function(y) {
d<-8
return(h(d,y))
}
>h
function(dee,yyy) {
}
print(ls())
print(ls(envir=parent.frame(n=1)))
return(dee
> f(2)
[1] "dee" "yyy"
[1] "d" "y"
[1] 112
*
(w+yyy))

>f
function(y) {
d<-8
return(h(d,y))
}
>h
function(dee,yyy) {
}
print(ls())
print(ls(envir=parent.frame(n=1)))
return(dee
> f(2)
[1] "dee" "yyy"
[1] "d" "y"
[1] 112
*
(w+yyy))

Avec parent.frame (), l'argument n spécifie le nombre d'images à monter dans la chaîne d'appel. Ici, nous étions en train d'exécuter h (), qui avait été appelé à partir de f (), donc spécifier n = 1 nous donne le cadre de f (), et ainsi nous obtenons ses locaux.

 

4 Les fonctions n'ont (presque) aucun effet secondaire
Une autre influence de la philosophie de la programmation fonctionnelle est que les fonctions ne changent pas les variables non locales; c'est-à-dire, généralement, il n'y a pas d'effets secondaires. Grosso modo, le code dans une fonction a un accès en lecture à ses variables nonlocales, mais il n'a pas accès en écriture à celles-ci. Notre code peut sembler réassigner ces variables, mais l'action n'affectera que les copies, pas les variables elles-mêmes. Démontrons cela en ajoutant un peu plus de code à notre exemple précédent.

>w<-12
>f
function(y) {
}
d<-8
w<-w+1
y<-y-2
print(w)
h <- function() {
return(d
*
(w+y))
}
return(h())
>t<-4
> f(t)
[1] 13
[1] 120
>w
[1] 12
>t
[1] 4

>w<-12
>f
function(y) {
}
d<-8
w<-w+1
y<-y-2
print(w)
h <- function() {
return(d
*
(w+y))
}
return(h())
>t<-4
> f(t)
[1] 13
[1] 120
>w
[1] 12
>t
[1] 4

Donc, w au niveau supérieur n'a pas changé, même s'il semble changer dans f (). Seule une copie locale de w, dans f (), a changé. De même, la variable de niveau supérieur t n'a pas changé, même si son argument formel associé y a changé.
NOTE Plus précisément, les références au local w vont en fait au même emplacement mémoire que le local, jusqu'à ce que la valeur du local change. Dans ce cas, un nouvel emplacement de mémoire est utilisé.
Une exception importante à cette nature en lecture seule des globaux se pose avec l'opérateur de super-assignement, dont nous parlerons plus loin dans la section 7.8.1.