[R] package environment versus namespace environment

Duncan Murdoch murdoch.duncan at gmail.com
Wed Mar 19 21:31:33 CET 2014


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 <markleeds2 at gmail.com
> <mailto:markleeds2 at 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.duncan at gmail.com <mailto:murdoch.duncan at 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 at r-project.org <mailto:R-help at 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 at r-project.org <mailto:R-help at 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 at r-project.org <mailto:R-help at 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/




More information about the R-help mailing list