[Rd] RFC: (in-principle) native unquoting for standard evaluation
h.wickham at gmail.com
Sun Mar 19 20:00:21 CET 2017
On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal <radford at 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
More information about the R-devel