Dear Emacs, make this -*-Text-*- mode! We need to make a decision re the ctest situation. My suggestion, as discussed with Brian, is the following: * Remove the autoloads (for {chisq,prop,t,wilcoxon}.test from the default profile (in src/library/profile/Common.R). * Advise users that they can add library(ctest) to a personal or site profile, if they want it by default. * Remove the diff.ts autoload, and for a later release work on making all the ts functionality be in library(ts). Some thoughts. * I basically view ctest as a *MODULE* providing certain functionality (here, classical tests). The objects this module exports are all the user level *.test functions, of course. An autoload mechanism as I understand it (my mind very much distorted by Emacs, of course) would basically make all exported objects `available' right away and load the whole module when it first comes across one of these objects. * There is really no point in deciding whether some classical test, e.g. var.test() is ``important'' enough to be autoloaded. Either we autoload all objects the module exports or none of them. * As long as we do not have a mechanism for automatically generating module autoloads from the code (e.g. the list of exported symbols) we should not manually manipulate autoload lists, but rather require the whole package. * My personal preference would in fact, as I guess everyone is aware of, be *NOT* to load any of ctest by default. I view R as an environment providing basic facilities for computation and graphics including an object system and maybe the basic modelling part, and everything else as add-on functionality which could an maybe should be made available in modules with a clear separation of external and internal symbols. Sort of like Perl, I guess. But I definitely do not regard ctest as part of the base system. * Having ctest functionality available by default may be desireable to some whereas others might prefer to have all multivariate analysis, or all time series functionality available by default. Enough said, I guess. Maybe in March we can talk a bit more about this and perhaps also figure out about ways to require add-on modules which are convenient to the user. Maybe expecting them to edit their personal .Rprofile is too much, and I have been told that site-wide profiles do not solve everything. So maybe we need a configuration menu with nice pulldowns that write .Rprofile. On a related issue, I think that we need to do something about package ts. It is wrong that I can generate ts objects using base functionality but need package ts to cbind them. Again, my preference would be to have a clean ts module. In any case, I think the diff.ts autoload should go.