KH-RFC-ctest

				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.