It seems mostly correct. Here are a few quibbles:
- I don't think "owner" is a good description of the parent environment.
Usually when I use owner in computing, there's an implication that the
owner controls what it owns, is responsible for allocating and
destroying it, etc. Parent environments are targets of a pointer from
other environments that list them as their "enclosure", but they have no
record of their children.
- The analogy that all roads lead to the search list is wrong. There's
no reason you couldn't create an environment whose parent was the empty
environment. But with the qualifier "when we start in R_GlobalEnv" it's
correct, so this complaint is just about the wording.
- The description of what Imports does is wrong. What is described
there is what the `import()` directive in NAMESPACE does. The Imports
line in DESCRIPTION just guarantees that the named package is loaded, it
doesn't import anything. And the `importFrom()` directive in NAMESPACE
isn't discussed.
- It gets bad near the end in the "Curveball" section. I'd just skip
that. It's not at all true that all functions in a package have the
package's namespace environment as their environment. There are lots of
real examples where that's not true. Functions that maintain persistent
records (e.g. the base function conflictRules()) often have a private
environment, and occasionally packages import functions from other
packages by simple assignment, so they end up in the namespace
environment of the importer but still have the namespace environment of
the exporter associated with them. And the last diagram (the revised
one with all solid lines) is just misleading.
Duncan
On 04/04/2023 7:53 p.m., Mark Leeds wrote:
obviously, everyone has different opinions on what's useful but I always
found this document quite
helpful. I think, in the past, someone said that there are some incorrect
statements in but I'm not sure
what they are.
https://askming.github.io/study_notes/Stats_Comp/Note-How%20R%20searches%20and%20finds%20stuff.html
On Tue, Apr 4, 2023 at 7:06 PM Bert Gunter <bgunter.4...@gmail.com> wrote:
The following *might* be of use to you. If you can predict what the various
function invocations will do, I think you have a reasonable grasp of how
lexical scoping works in R (contrary or supplementary opinions welcome).
It is the sort of thing you will find in the references also. If this is
all obvious, sorry for wasting your time.
#######################
search()
ls()
dat <- list(x =2)
attach(dat,2)
search()
f <- function(){
g <- function() x
x <- 3
g}
h <- f()
g <- function()x
ls()
h()
g()
detach(dat)
h()
g()
##########################
## Here is what this gives starting with an empty .GlobalEnv.
##################################
search()
[1] ".GlobalEnv" "package:tools" "package:lattice"
"tools:rstudio"
[5] "package:stats" "package:graphics" "package:grDevices"
"package:utils"
[9] "package:datasets" "package:methods" "Autoloads"
"package:base"
ls()
character(0)
dat <- list(x =2)
attach(dat,2)
search()
[1] ".GlobalEnv" "dat" "package:tools"
"package:lattice"
[5] "tools:rstudio" "package:stats" "package:graphics"
"package:grDevices"
[9] "package:utils" "package:datasets" "package:methods"
"Autoloads"
[13] "package:base"
f <- function(){
+ g <- function() x
+ x <- 3
+ g}
h <- f()
g <- function()x
ls()
[1] "dat" "f" "g" "h"
h()
[1] 3
g()
[1] 2
detach(dat)
h()
[1] 3
g()
Error in g() : object 'x' not found
-- Bert
On Tue, Apr 4, 2023 at 6:56 AM akshay kulkarni <akshay...@hotmail.com>
wrote:
Dear Members,
I have the following code typed at the
console prompt:
y <- x*10
X has not been defined and the above code throws an object not found
error. That is, the global environment does not contain x. Why doesn't it
look further in the environment stack, like that of packages? There are
thousands of packages that contain the variable named x. Of course, that
happens if the above code is in a function (or does it?).
What concept of R is at work in this dichotomy?
THanking you,
Yours sincerely,
AKSHAY M KULKARNI
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
