search for: _lazy_

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

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

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

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 <lawrence.michael at gene.com> wrote: > Interesting idea. Lazy and non-standard evaluation is going to happen; the > language