[Rd] RFC: (in-principle) native unquoting for standard evaluation

[Hadley Wickham]

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

Hadley

-- 
http://hadley.nz