From: hadley wickham <h.wickham_at_gmail.com>

Date: Tue, 11 Nov 2008 07:53:57 -0600

Date: Tue, 11 Nov 2008 07:53:57 -0600

On Mon, Nov 10, 2008 at 1:04 PM, Wacek Kusnierczyk
<Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no> wrote:

> pardon me, but does this address in any way the legitimate complaint of

*> the rightfully confused user?
**>
**> consider the following:
**>
**> d = data.frame(a=1, b=2)
**> a = c("a", "b")
**> z = a
**> # that is, both a and z are c("a", "b")
**>
**> subset(d, select=z)
**> # gives two columns, since z is a two element vector whose elements are
**> valid column names
**>
**> subset(d, select=a)
**> # gives one column, since 'a' (but not a) is a valid column name
**>
**> subset(d, select=c(a,b))
**> # gives two columns
**>
**>
**> this is certainly what the authors intended, and they may have good
**> grounds for this smart design. but this must break the expectation of a
**> naive (r-naive, for that matter) user, who may otherwise have excellent
**> experience in using a functional programming language, e.g., scheme.
**> (especially scheme, where symbols and expressions are first-class
**> objects, yet the distinction between a symbol or an expression and their
**> referent is made painfully clear, perhaps except for when one hacks with
**> macros.)
**>
**> the examples above illustrate the notorious problem with r that one can
**> never tell whether 'a' means "the value referred to with the identifier
**> 'a'" or "the symbol 'a'", unless one gets ugly surprises and is forced
**> to study the documentation. and even then one may not get a clear answer.
*

I agree, with some caveats. There are basically two uses of R: as a interactive data analysis package and as a statistical programming language. These uses come into conflict: in the interactive environment, you want to minimise typing so that you can be as speedy as possible. It doesn't matter if R occasionally makes a wrong guess when you have specified something implicitly, because you can fix it on the fly. When you are programming, you care less about saving typing and more about reproducibility. You want to be explicit so your function is robust to widely varying inputs, even if it means you have to type a lot more. You see this tension in quite a few places:

- drop = T
- functions that return different types of output (e.g. sapply) depending on input parameters
- partial matching of argument names
- using unevaluated expressions instead of strings (e.g. library, subset, ...)

These are all things that are helpful for interactive use, but make life as a programmer more difficult. I find the last one particularly frustrating because it means it is very difficult to program with some functions (i.e subset) without resorting to complex quoting, substituting and evaluating tricks. I have tried to steer away from this technique in my packages, and where it's just too convenient for interactive use, insulating the deparsing into special functions that the data analyst must use (e.g. aes() in ggplot, and .() in plyr), along with providing alternatives for the programmer.

I don't understand why you're getting so much push-back on this issue. R is a fantastic language, but it has some genuinely nasty corners. In my opinion, this is one of them.

Hadley

-- http://had.co.nz/ ______________________________________________ R-help_at_r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.Received on Tue 11 Nov 2008 - 13:56:22 GMT

Archive maintained by Robert King, hosted by
the discipline of
statistics at the
University of Newcastle,
Australia.

Archive generated by hypermail 2.2.0, at Tue 11 Nov 2008 - 21:30:24 GMT.

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