On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal <radf...@cs.toronto.edu> wrote: > Michael Lawrence (as last in long series of posters)... > >> Yes, it would bind the language object to the environment, like an >> R-level promise (but "promise" of course refers specifically to just >> _lazy_ evaluation). >> >> For the uqs() thing, expanding calls like that is somewhat orthogonal >> to NSE. It would be nice in general to be able to write something like >> mean(x, extra_args...) without resorting to do.call(mean, c(list(x), >> extra_args)). If we had that then uqs() would just be the combination >> of unquote and expansion, i.e., mean(x, @extra_args...). The "..." >> postfix would not work since it's still a valid symbol name, but we >> could come up with something. > > > I've been trying to follow this proposal, though without tracking down > all the tweets, etc. that are referenced. I suspect I'm not the only > reader who isn't clear exactly what is being proposed. I think a > detailed, self-contained proposal would be useful.
We have a working implementation (which I'm calling tidyeval) in https://github.com/hadley/rlang, but we have yet to write it up. We'll spend some time documenting since it seems to be of broader interest. > One thing I'm not clear on is whether the proposal would add anything > semantically beyond what the present "eval" and "substitute" functions > can do fairly easily. If not, is there really any need for a slightly > more concise syntax? Is it expected that the new syntax would be used > lots by ordinary users, or is it only for the convenience of people > who are writing fairly esoteric functions (which might then be used by > many)? If the later, it seems undesirable to me. I accidentally responded off list to Michael, but I think there are three legs to "tidy" style of NSE: 1) capturing a quosure from a promise 2) quasiquotation (unquote + unquote-splice) 3) pronouns, so you can be explicit about where a variable should be looked up (.data vs .end) These are largely orthogonal, but I don't think you can solve the most important NSE problems without all three. Just having 1) in base R would be a big step forward. > There is an opportunity cost to grabbing the presently-unused unary @ > operator for this, in that it might otherwise be used for some other > extension. For example, see the last five slides in my talk at > http://www.cs.utoronto.ca/~radford/ftp/R-lang-ext.pdf for a different > proposal for a new unary @ operator. I'm not necessarily advocating > that particular use (my ideas in this respect are still undergoing > revisions), but the overall point is that there may well be several > good uses of a unary @ operator (and there aren't many other good > characters to use for a unary operator besides @). It is unclear to > me that the current proposal is the highest-value use of @. A further extension would be to allow binary @ in function argument names; then the LHS could be an arbitrary string used as an extension mechanism. Hadley -- http://hadley.nz ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel