Hi Duncan: If you think there is anything incorrect in the document, I'd be interested because I refer to that document whenever I'm confused about namespaces, importing etc. Thanks.
On Wed, Mar 19, 2014 at 4:31 PM, Duncan Murdoch <murdoch.dun...@gmail.com>wrote: > On 14-03-19 1:18 PM, Suraj Gupta wrote: > >> As the author of that post, I must respond... >> >> # ----- first comment ------- >> >> Ducan: "The article that Henrik cited gives a reasonable description up >> until near the end" >> >> Suraj: Given the complexity of the topics at hand, the many accolades >> I've received for the post, and how thoroughly I've approached the topic >> and carefully navigated the user through rough terrain, I feel that >> characterizing my description as "reasonable" substantially shortchanges >> it. I wrote the post because the available descriptions (including >> those from well-established R community members) were confusing and >> filled with holes. >> > > Okay, next time I write about it I'll be sure to make the positive parts > more effusive in their praise. I can't remember all the details of my > complaints now (I wrote the quoted lines 10 days ago), and I doubt if > anyone would be interested in hearing them, so I'll just let them and your > responses stand. > > Duncan Murdoch > > >> # ----- next comment ------- >> >> Duncan: "...up until near the end, where (in my opinion) it makes things >> unnecessarily complicated" >> >> Suraj: I think Duncan is confusing iterative teaching, repetition, and >> thoroughness with complexity. These topics ARE complex. The need for a >> resource such as mine is a testament to that. My approach to complex >> topics is to break them down fully; to be diligent in the explanation so >> there are no leaps in logic. It's far more difficult to do that than to >> assume a reader can connect the dots and default to brevity. >> >> # ----- next comment ------- >> >> Duncan: "I'd recommend that you stop reading around where he tries to >> explain the dotted lines." >> >> Suraj: It's a disservice to yourself to stop here. This section >> provides a "light bulb" moment on the path to understanding the >> search/find mechanism. As stated in the blog post "Function execution >> is the most complex piece of the puzzle." I specifically encourage >> readers to re-read that section. Other resources will provide the same >> understanding, but it's likely a cumbersome process for the average >> reader. I synthesized these insights after laboring over words in books >> and articles, tinkering in R, and asking lots of questions. >> >> # ----- next comment ------- >> >> Duncan: "In particular, ignore the second version of the "Map of the >> World"; the first one is accurate, the second is just misleading" >> >> Suraj: A reader that doesn't understand the second Map cannot fully >> grasp the search/find mechanism. Everything in the post builds up to >> the second map. The second map encompasses function execution. I >> challenge anyone (in a friendly way) to create a better visualization of >> enclosing environments and function execution that allows a reader to >> easily navigate environment-space and figure out how R searches for >> symbols and where it finds them. I'll replace my map with yours if you >> can do that - we will all be better off for it! >> >> # ----- last comment ------- >> >> Duncan: "Gupta's article misses the possibility of packages that are >> loaded but not in the search path..." >> >> Suraj: I'm pretty sure I discuss all of this in "Imports v Depends" >> section. I have a diagram that shows package PLYR as loaded but not in >> the search path and I discuss it. >> >> >> On Wed, Mar 19, 2014 at 1:12 PM, Mark Leeds <marklee...@gmail.com >> <mailto:marklee...@gmail.com>> wrote: >> >> Hi Everyone: Suraj will respond to Duncan's comments below promptly. >> Suraj >> doesn't have the original thread so I am just helping out by >> commenting >> here so that he can respond and the thread can be kept continuous. >> >> Mark >> >> >> >> >> >> On Sun, Mar 9, 2014 at 9:09 AM, Duncan Murdoch >> <murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>wrote: >> >> >> > On 14-03-08 6:42 PM, Benjamin Tyner wrote: >> > >> >> Duncan, >> >> >> >> Thank you for the informative link. So, do the loaded namespaces >> have an >> >> "ordering" akin to the package search path that determines that >> >> functions in the base namespace can see objects in the utils >> namespace? >> >> (I noticed that loadedNamespaces() just comes back in >> alphabetical order.) >> >> >> > >> > No. The article that Henrik cited gives a reasonable description >> up until >> > near the end, where (in my opinion) it makes things unnecessarily >> > complicated. I'd recommend that you stop reading around where he >> tries to >> > explain the dotted lines. In particular, ignore the second >> version of the >> > "Map of the World"; the first one is accurate, the second is just >> > misleading. >> > >> > In answer to your question: Gupta's article misses the >> possibility of >> > packages that are loaded but not in the search path. In the >> notation of >> > the first part of that article, loading a namespace just puts it >> in the >> > middle two columns (i.e. creates the namespace and imports >> environments) >> > without putting it in the search list. That happens when you >> import or >> > load a package without attaching it. The search path imposes an >> ordering, >> > things that aren't in it aren't ordered. >> > >> > Duncan Murdoch >> > >> > >> > >> >> Regards >> >> Ben >> >> >> >> On 03/07/2014 11:46 AM, Duncan Murdoch wrote: >> >> >> >>> On 07/03/2014 10:16 AM, Benjamin Tyner wrote: >> >>> >> >>>> Hello, >> >>>> >> >>>> I realize that a function in <environment: base> (for example, >> function >> >>>> "head1" below) is unable to see (without resorting to "::", >> anyway) >> >>>> objects in utils (for example, "head" below), since >> package:base is >> >>>> after package:utils on the search path. >> >>>> >> >>> >> >>> >> >>>> However, I'm wondering what is the machinery that allows a >> function in >> >>>> <environment: namespace:base> (for example, function "head2" >> below) to >> >>>> be able to see "head" just fine, without needing to resort to >> "::". >> >>>> >> >>> >> >>> >> >>> See Luke Tierney's article in R News, >> >>> >> >>> Name space management for R. Luke Tierney, R News, 3(1):2-6, >> June 2003 >> >>> <http://cran.r-project.org/doc/Rnews/Rnews_2003-1.pdf> >> >>> >> >>> There's a link to it from the R help system. Run help.start(), >> then >> >>> look at "Technical papers" in the Miscellaneous Material section. >> >>> >> >>> I believe most of what it says is still current; the only thing >> I can >> >>> see at a glance that is no longer correct is that in those days >> >>> namespaces were optional in packages. Now all packages have >> namespaces. >> >>> >> >>> Duncan Murdoch >> >>> >> >>> >> >>>> I'm also wondering more generally, why there is a need >> (practically >> >>>> speaking) for a distinction between the environment associated >> with a >> >>>> package and the environment associated with the namespace. >> >>>> >> >>>> $ export R_PROFILE=/home/btyner/Rprofile.site >> >>>> >> >>>> $ cat /home/btyner/Rprofile.site >> >>>> sys.source("/home/btyner/head1.R", envir = baseenv()) >> >>>> sys.source("/home/btyner/head2.R", envir = >> .BaseNamespaceEnv) >> >>>> >> >>>> $ cat /home/btyner/head1.R >> >>>> head1 <- function(x) head(x) >> >>>> >> >>>> $ cat /home/btyner/head2.R >> >>>> head2 <- function(x) head(x) >> >>>> >> >>>> $ Rscript -e "head1(letters)" >> >>>> Error in head1(letters) : could not find function "head" >> >>>> Execution halted >> >>>> >> >>>> $ Rscript -e "head2(letters)" >> >>>> [1] "a" "b" "c" "d" "e" "f" >> >>>> >> >>>> $ Rscript -e "sessionInfo()" >> >>>> R version 3.0.1 (2013-05-16) >> >>>> Platform: x86_64-pc-linux-gnu (64-bit) >> >>>> >> >>>> locale: >> >>>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> >>>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >> >>>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >> >>>> [7] LC_PAPER=C LC_NAME=C >> >>>> [9] LC_ADDRESS=C LC_TELEPHONE=C >> >>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >>>> >> >>>> attached base packages: >> >>>> [1] stats graphics grDevices utils datasets base >> >>>> >> >>>> Regards >> >>>> Ben >> >>>> >> >>>> >> >>>> >> >>>> ______________________________________________ >> >>>> R-help@r-project.org <mailto:R-help@r-project.org> mailing list >> >> >>>> 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 <mailto:R-help@r-project.org> mailing list >> >> > 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 <mailto:R-help@r-project.org> mailing list >> >> 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. >> >> >> >> >> -- >> Best Regards, >> Suraj >> http://obeautifulcode.com/ >> > > [[alternative HTML version deleted]] ______________________________________________ R-help@r-project.org mailing list 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.
