Re: R-alpha: personal libraries -- why not use same UI as S-plus [i.e. lib.loc]?

Kurt Hornik (
Fri, 13 Dec 1996 17:24:20 +0100

Date: Fri, 13 Dec 1996 17:24:20 +0100
Message-Id: <>
From: Kurt Hornik <>
Subject: Re: R-alpha: personal libraries -- why not use same UI as S-plus [i.e. lib.loc]?

>>>>> On Fri, 13 Dec 96 11:46:50 +0100,
>>>>> Martin Maechler <> said:

> Given recent proposal (of Kurt I think) about making
> library(.) not only search in $RHOME,

> I think we could well adopt the "UI" of S-plus,
> (which we have been using quite a while here, in order to have
>  our own libraries always available even when S-plus versions change...).

> This went over S-news yesterday:

>>> ------- Start of forwarded message -------
>>> From: (Bruce Kendall)
>>> Date: Thu, 12 Dec 1996 14:19:26 -0800
>>> To: Snews <>
>>> Subject: personal libraries
>>> Thanks to all the folks who answered my question about accessing personal
>>> library collections with the library() command.  Charles Kincaid gave a nice
>>> summary:
>>> If you have the book of inestimable value that is
>>> lovingly known as "the yellow book", i.e. Venables & Ripley's Modern
>>> Applied Statistics in S-plus, then they explain how to do this for their
>>> libraries.
>>> If you look at the documentation for the library function, then it
>>> outlines these details also.  Essentially, you can assign the path to the
>>> library as a value to "lib.loc" in database 0.  For example,
>>> > assign(where=0, "lib.loc", "/path/to/my/library")
>>> The optimal place for this is in your .First function.  Then you can just
>>> use the library command as usual.

As it seems that lib.loc could actually be a list of directories, this
would be o.k., I think.

On the other hand, I think that there are similar situations where R is
looking for 
	shared libs

I think that in each case, there should be a list of directory
hierarchies to go through.  E.g., something like


or perhaps even with a finer distinction between what is provided by the
main distribution e.g. in
and the site-wide add-ons in
(similar to the Emacs organization).

And of course, the mechanism does not necessarily have to be based on
environment variables.

Anyway, if we don't necessary want to have "." in the paths and are only
looking for scanning various similar `R trees', it may be easier to have
e.g. system.file() look through the trees and return what is found
first.  This could be controlled through a variable like R_PATH.

But then, things which e.g. should list all indices will not work.  Hmm.

What do others think about having several R trees?  (in the long run, I


r-testers mailing list -- For info or help, send "info" or "help",
To [un]subscribe, send "[un]subscribe"
(in the "body", not the subject !)  To: