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

ML> For the uqs() thing, expanding calls like that is somewhat orthogonal ML> to NSE. It would be nice in general to be able to write something like ML> mean(x, extra_args...) without resorting to do.call(mean, c(list(x), ML> extra_args)). This is not completely true because splicing is

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

RN> There is an opportunity cost to grabbing the presently-unused unary @ RN> operator for this I don't think this is the case because the parser has to interpret `@` in formal argument lists in a different way than in function calls. Besides, it'd make sense to set up these annotations with a

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

On Mon, Mar 20, 2017 at 8:00 AM, Hadley Wickham wrote: > On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal wrote: >> Michael Lawrence (as last in long series of posters)... >> >>> Yes, it would bind the language object to the environment, like an >>>

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

On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal 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_

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

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

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

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

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

Firstly, credit where due: the lazyeval NSE vignette [1] covers so many of the angles that this proposal needs to address and is extremely well written (even if it has been superseded). The @ prefix I'm proposing is a drop-in replacement for `uq()` (as used in that vignette) but for which the

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

Would this return a quosure? (i.e. a single sided formula that captures both expression and environment). That's the data structure we've adopted in tidyeval as it already has some built in support. Hadley On Friday, March 17, 2017, Michael Lawrence wrote: >

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

What would you propose for the unquote-splice operator? Hadley On Friday, March 17, 2017, Jonathan Carroll wrote: > (please be gentle, it's my first time) > > I am interested in discussions (possibly reiterating past threads -- > searching didn't turn up much) on the

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

Jonathan, Nice proposal. I think these two uses for unary @ ( your initial @ unary operator and Michael's extension for use inside function declaration) synergize really well. It could easily be that function owners can declare an parameter to always quote, and function callers can their

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

Not sure I totally understand what you wrote, but my proposal is somewhat independent of the unquoting during the call (your proposal). Authors would be free to either use auto-quoting or continue to rely on the substitute() mechanism. Lazy evaluation wouldn't go away. On Fri, Mar 17, 2017 at

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

I love the pointer analogy. Presumably the additional complication of scope breaks this however. * itself would have been a nice operator for this were it not prone to ambiguity (`a * *b` vs `a**b`, from which @ does not suffer). Would this extension require that function authors explicitly

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

Interesting idea. Lazy and non-standard evaluation is going to happen; the language needs a way to contain it. I'll extend the proposal so that prefixing a formal argument with @ in function() marks the argument as auto-quoting, so it arrives as a language object without use of substitute(). Kind

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

(please be gentle, it's my first time) I am interested in discussions (possibly reiterating past threads -- searching didn't turn up much) on the possibility of supporting standard evaluation unquoting at the language level. This has been brought up in a recent similar thread here [1] and on