Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)

From: A.J. Rossini <>
Date: Thu 10 Feb 2005 - 06:07:02 EST

On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik <> wrote:
> >>>>> Peter Dalgaard writes:
> > Kurt Hornik <> writes:
> >> >>>>> A J Rossini writes:
> >>
> >> > But I don't see a problem with "package("package")", though I'm sure
> >> > I'm missing something.
> >>
> >> package() [sic] might be the creator for package objects, provided we
> >> can decide on what they are (and what kind of packages [source,
> >> installed, ...] they are used for).
> >>
> >> usePackage() or use_package() otoh would indicate to "use" a package
> >> (i.e., load and attach it). The tricky part is deciding about the
> >> interface (e.g., finally disallowing non-standard evaluation as it is a
> >> programmer's nightmare) and what it should return. And that is work in
> >> progress ...
> > Any information on the rate...? (I still vote for usepackage() btw.)
> Why not use(), as the GCD?

Excellent suggestion, Kurt.

> > It would be good if we could at least have an outline of the intended
> > functionality and see if we could forge ahead and get a preliminary
> > version done in time for 2.1.x
> Help us out.
> use <- function(package, pos = 2, lib.loc, ...)

use <- function(packageName,pos=2,library, ...)

I could argue that "library" and "lib.loc" try to describe the same thing (a name and its pointer).

> where 'package' is either a character string or some sort of package
> object/reference, to be specified later. And 'lib.loc' needs to have a
> different name if we rename libraries into stores or whatever ...

I think package ought to be a character string. Unless you want to combine the packageName and libraryLocation into some form of data object, or packageName, libraryLocation, and an environment containing the erstwhile contents?

> What should this return? Currently, 'library' returns the list of
> loaded (or available) packages by default, as a list of names, which is
> not good enough. So we need something like the DLLInfoList returned by
> getLoadedDLLs() (and the docs should actually mention that class), or
> something usable by the package management tools ... and this is under
> redesign as well.

Perhaps "use" should incorporate "require" functionality, i.e. TRUE or FALSE depending on whether you can use it after the "use" function call.

> But why should this really return info on all loaded/attached packages?
> An alternative might be just returning the package meta-data in some
> form. Or nothing, which would fit into the idea that it really does
> nothing apart from loading and attaching a package.

I like "libraryContents()" or similar to figure out loaded and potentially loadable packages.

> (And maybe a condition object inheriting from packageLoadAndAttachError
> in case of failure? :-))

Yes. whatever.


"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

A.J. Rossini

______________________________________________ mailing list
Received on Thu Feb 10 05:27:28 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:50 EST