[Rd] RE: [R] debugging non-visible functions

[Prof Brian Ripley]

On Wed, 13 Oct 2004, Duncan Temple Lang wrote:

> Prof Brian Ripley wrote:
> > On Wed, 13 Oct 2004, Liaw, Andy wrote:
> > 
> > 
> > > On a slightly different topic:  In R-2.0.0, packages with NAMESPACE no
> > > longer need to use the package= argument in .C/.Fortran.  Does that mean if
> > > I remove those arguments, I should put R version >= 2.0.0 in the Depend
> > > field of the DESCRIPTION?
> > 
> > I think you should not remove the PACKAGE= (sic) arguments.  There has
> > been little (none I have seen) discussion of that change, and Duncan TL
> > will be able to elucidate.  But the reason given in NEWS to omit them
> > relates to loading more than one versioned install of a package at once,
> > something we were told originally by Robert G was not intended to be
> > allowed (and that is assumed in quite a few places in the code -- there is
> > no way to have imports from a version of a namespace, for example -- and
> > indeed importing from versioned install of namespaces did not work in
> > 2.0.0).  Duncan?
> 
> 
> The reason in the NEWS file is exactly the motivation.
> It is for cases where one explicilty loads a package (A) via the library() function,
> and a different version of that package is imported indirectly  
> when loading another package via a dependency on an explicit 
> version of A.   And this is also the case when two packages (B and C)
> require different versions of the original package. 
> A less pressing but useful use example is when one wants to compare
> results from different versions as one develops new releases.
> And similarly for reproducible research, we often need explicit
> versions of packages within a larger context of an existing R session.
> There are easy work arounds for some of these, but they are cumbersome.

The question is: does allowing simultaneous loading of versions actually
help solve these problems?

> I don't recall the exact details of Robert's original 
> statements on this topic.  As with many features
> introduced in R, the initial work (e.g. on namespaces) is not entirely functional
> for all advanced, less-used aspects of other features being introduced.
> So we will have to allow a NAMESPACE to import from
> a particular version as things evolve. It is an issue,
> but I don't think we want to prohibit having
> different versions of a package loaded concurrently.
> Using a namespace provides a convenient way to find
> the associated DLL.  We can also explicitly identify

Thanks for the clarification.  Some of us were not aware that this was a
design goal, and it will be good to bear it in mind.  

HOWEVER, I don't see we have any feasible solution without namespaces,
since whichever version is loaded last wins in the usual scoping rules.  
If B requires A version 1 and C requires A version 2 and they are loaded
in that order the search path will be

C A_2 B A_1 (using Depends) or A_2 C A_1 B (using require)

and code in B will find objects from A_2 if they are in there.  Without
versioned namespace imports I don't see how this helps: am I missing
something?  (In R<=2.0.0 if you have a namespace in A you can't import
from it, at least in any way compatible with non-versioned installs.)

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595