>> Some of us (including me) have strongly argued on several >> occasions that global options() settings should *not* have an effect >> on anything "computing" but just on "output" >> i.e. printing/graphing of R results. >> As it is currently, potentially R scripts and R functions may >> only work correctly for one setting of >> options( stringsAsFactors = * ) >> which is against all principles of functional programming. > > A similar argument would also seem to apply to defaultPackages, > deparse.max.lines, download.file.method, encoding, expressions, warn > and na.action. There are plenty of functions in R that violate other > principles of functional programming, so, by itself, this argument > seems a little weak to me. There are obviously differences of opinion > about this issue in R core, and it's unfortunate that the user has to > be exposed to them through inconsistent function definitions.
Which isn't to say I don't think that you're right - I would hate for R to head in the direction of PHP where every script has to check three or four different global variables in order to work on all installations. Hadley -- http://had.co.nz/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
