[R] Workings of model.frame.default and [.

[Prof Brian D Ripley]

This is really a question of S language design.  A factor is an enumeration
type, and there are many good reasons why one does not change the baseset
of an enumeration type.  (Indeed a lot of errors have stemmed from a
failure to check that the enumeration set is used consistently.)

The view is that global options which allow departures from the existing
language specification are a very bad idea.  Not only would R-core need to
devise checks for all the base code under the all possible sub-languages,
but so would all the package contributors.  And users would get confused
as code became unreproducible.

As from 1.6.0, redefining base functions will have a much more limited
effect, being ignored when called from any function in base (and any other
function in a namespace).


On Tue, 30 Jul 2002, David Kane  <David Kane wrote:

> Frank E Harrell Jr writes:
>
> > Thanks again, and I'll put in one more plug for [.factor to be modified so
> > that if a system option 'drop.unused.levels' is TRUE (i.e., NOT by default)
> > drop=TRUE is assumed unless drop=FALSE is explicitly stated by the user.
> > Then I can dispose of my local [.factor once and for all.
>
> I'll second this notion. Although a wiser man than I would hesitate to comment
> on the relationship between R-core and Professor Harrell, it would seem a nice
> thing for R-core to do to "Welcome Aboard" Professor Harrell to the land of R,
> given his many contributions (Hmisc, Design, et cetera) to the S language over
> the years.
>
> Of course, there is probably some deep design issue why this is hard to do or
> some (obvious) statistical reason why one would not want R to provide this much
> "rope" to unsophisticated users. If so, I would enjoy being educated about the
> issues involved.

People hang themselves if provided with rope ....

> In my own small corner of the world, I would use such an option. One of the
> biggest complaints that my colleagues have about dataframes is precisely this
> behavior. It was also one of my own biggest confusions when starting with S+.
>
> Just my 2 cents,
>
> Dave Kane
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>

-- 
Brian D. Ripley,                  ripley at 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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._