Hi Faheem!
(apologies again to group...accidentally erased Faheem''s
personal e-mail address. just back from vacation and fuzzy-headed)
The best way to un-puzzle yourself is to look at the
original S Book: "The New S Language", Becker, Chambers, and
Wilks, from 1988.
Pls. look in Section 5.4, p. 117. This section describes
how frames and such work in S of that time.
Then you can do a nice "compare-and-contrast" to the VR material,
which
is excellent, by the way.
The gist of the section is that operations take place in different
"locations", if you will.
The best way to see this is to write a function in R, check
how/when it is evaluated, and then do the same thing in S/SPlus. (it''s
a very interesting exercise!!!)
Hope this helps!
Sincerely,
Erin M. Hodgess, Ph.D.
Assistant Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
One Main Street
Houston, TX 77002
e-mail: hodgess at uhddx01.dt.uh.edu
Subject: [R] environments and lexical scoping (conceptual issues)
Dear R people,
I have been reading about R in V&R''s `S programming'',
specifically Section
3.4, entitled `Databases, frames, and environments''.
I have found it useful in helping me understand things which I had
previously found puzzling. However, there are still some things I don''t
fully understand. Could some kind person help me clarify them? For
instance, I am having difficulties with the latter part of the
following passage (pgs 63,64), which is entirely about R. Quoting:
VR> `Lexical scoping'' comes into play when we consider how R finds
objects
VR> to associate with names when evaluating a function. In principle the
VR> answer is easy: it searches the `environment'',that is in the
frame of
VR> the environment, then in the frame of the enclosing environment, then
VR> in the frame of the enclosing environment of the enclosing environment,
VR> and so on. In less precise language, it searches up the tree of
VR> environments until it finds a match or reaches the root, which will be
VR> the user''s workspace, and then along the search path.
Ok, clear so far.
VR> So, we need to know where the evaluation environment is on the tree of
VR> environments. When the evaluation environment is a function body, the
VR> enclosing environment is that of the function, which is normally the
VR> environment within which the function was defined. This is what is
VR> meant by lexical scoping.
Still clear...
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?
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.
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?
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.
Faheem.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._