Re: [Rd] [R] R drop behavior -- set as option in later version?

From: Martin Maechler <maechler_at_stat.math.ethz.ch>
Date: Fri 08 Sep 2006 - 13:13:31 GMT

>>> Balaji S. Srinivasan <balajis <at> stanford.edu> writes:

    Balaji> I know the topic of drop=TRUE/FALSE has been     Balaji> discussed quite a bit,

 { indeed and often enough by great minds so that at one point in time    newcomres could believe it was not worth the pain to take it up again ...    There are many much more interesting problems to be tackled!  }

    Balaji> discussed quite a bit, but I was wondering whether
    Balaji> it might be possible to set "drop=FALSE" as a global
    Balaji> setting (e.g. as an option in options()) so that one
    Balaji> does not have to remember ...................

   [..........]

No, no, no!

In my book, options() should *NEVER* change fundamental behavior of function of the S language (nor its R implementation).

Ideally, options() should only influence printed output; pragmatically a few exceptions have been allowed, but for some of them I'm not sure it was a wise decision to introduce.

One of the major features and beauties of S it's that it is a functional language {in most respects} and functions --- think about a function in the mathematical sense! --- should not return different results for the same function arguments depending on some ``outer settings''.

At the first DSC meeting 1999 (and/or the second, 2001 ?), several of the R developers had several chats with John Eaton, author of GNU octave [the first matlab clone], and I think he also had a talk on this:
He said one of the biggest mistakes (or even the only real bad mistake) he made in octave development was to allow such options, more and more, on user requests {many for matlab compatibility, and matlab was inferior sometimes, and later changed itself, etc etc}

    Balaji> I searched in R-help and did not see any previous     Balaji> proposals along these lines,

for good reasons:

  1. it does not at all belong to R-help, but to R-devel
  2. if you think more about it, as Gregor has in parts,

       see below.

 [..............]

    Gregor> I agree with you that you find yourself typing the
    Gregor> same constructs over and over. I think that we need
    Gregor> to distinguish two modes of working with R. If you
    Gregor> do analysis, then you can really get tired of typing
    Gregor> drop=FALSE, na.rm=TRUE etc.  But this things are
    Gregor> very important when you are programming in R. Since
    Gregor> these two modes are not really separated in R I do
    Gregor> not think this is an easy task, but it would be
    Gregor> great to have it. I had recently the same question
    Gregor> for na.rm=TRUE.  But imagine how hard would it be to
    Gregor> have two separate modes ... argh, probably a mess^2
    Gregor> or have I missed something obvious.

Yes, exactly : "Mess ^ 2" --- and if you allow both 'drop' and 'na.rm' options, it's "Mess ^ 3" -- not something anyone really wants!

In the history of S, I think there have been several attempts of having a hack and an ``own local better'' version of S (or R), sometimes indeed implemented even via such an options() setting.

Longer term it always becomes a maintenance nightmare (unless you want to entirely decouple from the rest of the progammeRs)! Particularly with the high quality assurance code in effect for R packages -- how could you try to ensure that all packages work correctly with all such possible options() setting combinations ??

Martin Maechler, ETH Zurich



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri Sep 08 23:17:05 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Fri 08 Sep 2006 - 14:30:05 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.