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