[Rd] Trying to understand the search path and namespaces

[Berwin A Turlach]

G'day Hadley,

On Tue, 16 Nov 2010 07:35:09 -0600
Hadley Wickham <hadley at rice.edu> wrote:

> > Well, as the part of "Writing R Extensions" that Martin quoted
> > states, the normal search path is part of the search path used by
> > packages with name spaces.  So if you attach another package via
> > library(), the normal search path changes and, hence,
> > `parents(getNamespace("devtools"))' has one more location to report.
> 
> It's still not at all obvious how this happens - when does variable
> look up use the stack of environments given by the package environment
> and when does it use the stack of environments given by the namespace?

Well, if we are going to nitpick, the former presumably never
happens. :)  Section 3.5.4 "Search path" of the "R Language Definition"
might be more illuminating than quotes from "Writing R Extensions".

The first two paragraphs of that section are :

	In addition to the evaluation environment structure, @R{}
	has a search path of environments which are searched for
	variables not found elsewhere.  This is used for two things:
	packages of functions and attached user data.

	The first element of the search path is the global environment
	and the last is the base package.  An @code{Autoloads}
	environment is used for holding proxy objects that may be
	loaded on demand.  Other environments are inserted in the path
	using @code{attach} or @code{library}.

I guess this is what you refer to by "stack of environments given by the
package environment" (though it clearly isn't, if the object/variable
is not found in the evaluation environment structure [I guess Section
3.5.2 "Lexical environment" explains what this is], the search starts in
the global environment, not the environment of the package).  The third
and last paragraph of Section 3.5.4 states:

	Packages which have a @emph{namespace} have a different search
	path. When a search for an @R{} object is started from an
	object in such a package, the package itself is searched first,
	then its imports, then the base namespace and finally the
	global environment and the rest of the regular search path.
	The effect is that references to other objects in the same
	package will be resolved to the package, and objects cannot be
	masked by objects of the same name in the global environment or
	in other packages.

I hope this clarifies your remaining doubts about the process.  

Cheers,

	Berwin