Calls of the form data(package = pkg) inside a function incorrectly fail ("pkg" is a local variable). For instance, foo <- function(pkg) data(package = pkg) foo("base") Error in .find.package(package, lib.loc, verbose = verbose) : none of the packages were found ## workaround -- force argument "package" to be an expression ## (not a name) foo <- function(pkg) data(package = as.character(pkg)) all.equal(data(package = "base"), foo("base")) [1] TRUE The cause is the following piece of code inside data() > print(data) .... if (!missing(package)) if (is.name(y <- substitute(package))) package <- as.character(y) ... namely, when data() is invoked from within a function, e.g., data(package = pkg), the argument "package" inside data() is indeed a name, but not one that should be coerced to character as when one types data(base) from the R prompt, but rather simply a variable in the calling function; in the example above, the arg "package" to data() is effectively computed to be "pkg", which (luckily) does not correspond to any attached package. version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Patched major 1 minor 8.0 year 2003 month 10 day 13 language R -- David A. James Statistics Research, Room 2C-253 Phone: (908) 582-3082 Bell Labs, Lucent Technologies Fax: (908) 582-3340 Murray Hill, NJ 09794-0636
David James <dj@research.bell-labs.com> writes:> Calls of the form data(package = pkg) inside a function > incorrectly fail ("pkg" is a local variable). For instance, > > foo <- function(pkg) data(package = pkg) > foo("base") > Error in .find.package(package, lib.loc, verbose = verbose) : > none of the packages were foundThis is pretty much unavoidable if you want a function to accept unquoted names. It's not in principle different from women <- "airquality" data(women) not being equivalent to data("airquality"). Some functions (library(), require(), demo()) have a character.only argument to prevent it, and I suppose we should consider putting it on help() and data() as well. Meanwhile, my preferred device is foo <- function(pkg) eval(substitute(data(package))) -p -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
Yes, but this is not to do with being inside a function: pkg <- "base" data(package=pkg) ilustrates it, and library etc behave in the same way (except library can make use of character.only = TRUE). You can use substitute, too, as in foo <- function(pkg) eval(substitute(data(package = pkg), list(pkg=pkg))) On Thu, 16 Oct 2003, David James wrote:> Calls of the form data(package = pkg) inside a function > incorrectly fail ("pkg" is a local variable). For instance, > > foo <- function(pkg) data(package = pkg) > foo("base") > Error in .find.package(package, lib.loc, verbose = verbose) : > none of the packages were found > > ## workaround -- force argument "package" to be an expression > ## (not a name) > > foo <- function(pkg) data(package = as.character(pkg)) > all.equal(data(package = "base"), foo("base")) > [1] TRUE > > The cause is the following piece of code inside data() > > > print(data) > .... > if (!missing(package)) > if (is.name(y <- substitute(package))) > package <- as.character(y) > ... > > namely, when data() is invoked from within a function, e.g., > data(package = pkg), the argument "package" inside data() is indeed > a name, but not one that should be coerced to character as when one > types data(base) from the R prompt, but rather simply a variable > in the calling function; in the example above, the arg "package" > to data() is effectively computed to be "pkg", which (luckily) > does not correspond to any attached package. > > version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status Patched > major 1 > minor 8.0 > year 2003 > month 10 > day 13 > language R > >-- Brian D. Ripley, ripley@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
There seem to be two opposing yet valid viewpoints to the question of doing it right vs. compatibility with S-Plus. Compatbility with older version of R is a third overlapping possible goal. There does not appear to be an overall statement of intent in R, but rather, this question and others are approached on a case by case basis. Scoping is an example where R took the first route and the feature in question is an example of the second. There are undoubtedly many more possible examples. One possibility might be to do it right, by default, but have a package that, when loaded, gives you S-Plus compatibility (or visa versa). This would cover not only this feature but other features where there was a desire to do it right. Some things that are difficult to implement in two ways, such as scoping, would presumably not be handled by this but other simpler items such as the one in question could be. --- Date: Fri, 17 Oct 2003 09:28:59 +0200 From: Martin Maechler <maechler@stat.math.ethz.ch> [ Add to Address Book | Block Address | Report as Spam ] To: <Kurt.Hornik@wu-wien.ac.at> Cc: David James <dj@research.bell-labs.com>, <r-devel@r-project.org>,Peter Dalgaard <p.dalgaard@biostat.ku.dk> Subject: Re: [Rd] data() misbehaving inside a function>>>>> "KH" == Kurt Hornik <Kurt.Hornik@wu-wien.ac.at> >>>>> on Fri, 17 Oct 2003 09:04:40 +0200 writes:>>>>> Peter Dalgaard writes: >> David James <dj@research.bell-labs.com> writes: >>> Calls of the form data(package = pkg) inside a function >>> incorrectly fail ("pkg" is a local variable). For instance, >>> >>> foo <- function(pkg) data(package = pkg) >>> foo("base") >>> Error in .find.package(package, lib.loc, verbose = verbose) : >>> none of the packages were found>> This is pretty much unavoidable if you want a function to accept >> unquoted names. It's not in principle different from>> women <- "airquality" >> data(women)>> not being equivalent to data("airquality"). Some functions (library(), >> require(), demo()) have a character.only argument to prevent it, and I >> suppose we should consider putting it on help() and data() as well.KH> Or get rid of non-standard evaluation and educate users to use quoted KH> strings where strings should be used. and infuriate those who know and used the S language for more than 15 years, where help(help) has always worked? Definitely not worth the pain (I *know* I'd hear ... comments from them!)! I'd go for adding `character.only'. Martin _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com
Gabor Grothendieck wrote:> > There seem to be two opposing yet valid viewpoints to the > question of doing it right vs. compatibility with S-Plus. > Compatbility with older version of R is a third overlapping > possible goal. > > There does not appear to be an overall statement of > intent in R, but rather, this question and others are > approached on a case by case basis.I think this point was discussed and settled a long time ago. It may actually pre-date the mail archives: 1/ Do it right. 2/ If it does not conflict with 1/, have S-plus compatibility. 3/ If back compatibility with older versions of R cannot be maintained to accomplish 1/ then make the transition as painless as possible and try to isolate the screaming to remote locations like Seattle and Ottawa :). I would say that eliminating "_" for assignment is a pretty strong indication of how much 1/ dominates. The main problem seems to be that it sometimes takes awhile to know what "right" is, and in the meantime 2/ dominates. Paul Gilbert