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

[Martin Maechler]

       >>> 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