[R] environments and lexical scoping (conceptual issues)

[Peter Dalgaard BSA]

Faheem Mitha <faheem at email.unc.edu> writes:

> VR> The enclosing environment need not be the parent environment, the 
> VR> environment from which the evaluation environment was created, and
> VR> [the enclosing environment (my addition)] is usually the environment
> VR> within which the function was created, often the workspace.
> 
> ?? I don't understand. If "the enclosing environment need not be the
> parent environment, from which the evaluation environment was created"
> then this seems to contradict the previous para, where it says "When the
> evaluation environment is a function body, the enclosing environment is
> that of the function, which is normally the environment within which the
> function was defined." Does the last para refer to situations other than
> functions defined within functions? If so, an example of this would be
> helpful in understanding what is meant. And if the enclosing environment
> is not the parent environment, then how is the enclosing environment
> chosen? 

This is crucial. You have to distinguish between the *defining*
environment and the *calling* environment. 

 x<-5
 f<-function()x 
 g<-function(){x<-2;f()}
 g() # == 5

The converse would be

 g<-function(){x<-2;function()x}
 h<-g()
 x<-5
 h() # == 2

There are situations beyond defining functions inside other functions,
for instance 

 k <- evalq(function(n)x+n, environment(h))
 k(2) # == 4


> VR> Notice that the end effect is somewhat similar to that of S; the 
> VR> frames of the parents of the function are not normally searched, so
> VR> the search goes from the local environment to the user's workplace, and
> VR> then along the search path given by search() (as the enclosing
> VR> environment of all functions in packages is set to the workspace).
> VR> However, the scope is different for functions defined within other
> VR> functions. (A function's environment can be changed by using
> VR> environment as a replacement function, a complication we will not
> VR> explore here.)
> 
> This seems to confirm that functions defined within other functions *are*
> treated differently, ie. by lexical scoping, whereas environments created
> by other means are not necessarily.

Not really. Environments are always lexically scoped. The enclosure is
the environment in which the environment was defined. Functions are
special only in the sense that they carry the environment in which
they are defined (this is the concept of "function closures"). When
you are defining a function within another function that environment
is the execution environment of the function that calls "function",
unless you explicitly set the environment differently using e.g. eval().

> The phrase "(as the enclosing environment of all functions in packages is
> set to the workspace)" is also confusing me. Is the enclosing environment
> in this case being forced to be the user's workplace, and is this an
> example of the enclosing environment not being the parent environment?

Exactly. Have a look at library(). Notice that packages are loaded
with

 sys.source(file, env, keep.source = keep.source) 

This makes all loaded functions be defined in "env", but it has the
side effect that their enclosing environment is also "env". That is
not practical because then a function in a package cannot "see"
definitions in the global environment or for that matter in later
packages, hence the chasing

 .Internal(lib.fixup(env, .GlobalEnv))

> The discussion in `S Programming' is by far the most detailed of these
> important concepts that I have seen, but it would be even more useful if
> it were made more wordy and more (simple) examples were given, so as to
> make misunderstandings more difficult. I have read the preceding passage a
> number of times, but as you can see its meaning is still not fully clear
> to me, and I have not been able to find any documentation that sheds
> further light on the concepts discussed here.

Also have a look at:

Ihaka & Gentleman (1996), "R: A Language for Data Analysis and
Graphics", Journal of Computational and Graphical Statistics, 5,
299-314.

There's an R language manual on the drawing board, and it is supposed
to contain material of this caliber, but writing it is a slow process.
(As you will have noticed, it is necessary to be both comprehensive
and comprehensible, and achieving both goals can be difficult.)

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._