[R] package environment versus namespace environment
Duncan Murdoch
murdoch.duncan at gmail.com
Mon Mar 10 12:28:37 CET 2014
On 14-03-09 1:59 PM, Benjamin Tyner wrote:
> Duncan,
>
> Thanks for the explanation and commentary. Starting to make more
> sense...so, long story short, it seems the first thing one should check
> is whether base imports utils:
>
> > packageDescription("base")
> Package: base
> Version: 3.0.1
> Priority: base
> Title: The R Base Package
> Author: R Core Team and contributors worldwide
> Maintainer: R Core Team <R-core at r-project.org>
> Description: Base R functions
> License: Part of R 3.0.1
> Built: R 3.0.1; ; 2013-10-16 10:50:56 UTC; unix
>
> -- File: /usr/lib/R/library/base/Meta/package.rds
>
> I'll interpret the lack of an "Imports:" line to mean that base does not
> import any packages. So then the next thing to check is the enclosing
> environment:
>
> > parent.env(.BaseNamespaceEnv)
> <environment: R_GlobalEnv>
>
> Ah-ha! Unlike the base package environment, the base namespace
> environment has its enclosing environment already on the search path, so
> eventually leads back to utils. (This is the piece of the puzzle
> prompting my original question about "... machinery that allows ...")
>
> So hypothetically, if I had attached utils ahead of .GlobalEnv on the
> search path, then functions in the base namespace would no longer be
> able to see objects in utils? (I realize the answer may be vacuous,
> since library() does not honor pos=1).
I suspect in that alternate universe the base namespace would still be
parented by the first entry in the search list.
Duncan Murdoch
>
> Regards,
> Ben
>
>
> On 03/09/2014 09:09 AM, Duncan Murdoch 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 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.
>>>>
>>>
>>>
>>> --
>>> //
>>
>
>
> --
> //
More information about the R-help
mailing list