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 `f_eval()` and `~` steps would not be required by the author/user.
This is proposed as an admittedly naive suggestion which fails to account for the subtleties raised in [1] such as unquoting of multiple arguments and scope selection. I am hoping that the discussion can cover how best to address those matters. The significant hurdles (apart from implementation which I cannot speak to) that are dealt with in lazyeval (and presumably tidyeval) seem to be: - a prefix can be attached to only a single object, so the extra_args example from [1] would not be possible. I'm not certain why the unquoting of the variable would not still be possible with the form variable = "x" mean(@variable, na.rm = TRUE, trim = 0.9) since I'm proposing that the call need not be a formula (I may be way off on this interpretation). - I am proposing that the new syntax be able to achieve the example f <- function(col1, col2, new_col_name) { mtcars %>% mutate(@new_col_name = @col1 + @col2) } but this is ambiguous if there is, say, an object "mpg" within that function scope. [1] handles this with .env and .data pronouns but this doesn't seem possible with just a prefix. One solution may be to have @@ and @ representing these two options. I appreciate the significant work that has gone into the tidyverse packages which use NSE and my intention is not to downplay any of that. I would just like to be able to use the language more efficiently, so native access to the unquoting seems like a step forward. Kindest regards, - Jonathan. [1] https://cran.r-project.org/web/packages/lazyeval/vignettes/lazyeval.html On Sun, Mar 19, 2017 at 1:09 PM, Hadley Wickham <h.wick...@gmail.com> wrote: > 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.mich...@gene.com> > wrote: > >> 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 of like how '*' in C declares a >> pointer and dereferences one. >> >> subset <- function(x, @subset, ...) { } >> >> This should make it easier to implement such functions, simplify >> compilation, and allow detection of potential quoting errors through >> static >> analysis. >> >> Michael >> >> On Thu, Mar 16, 2017 at 5:03 PM, Jonathan Carroll <j...@jcarroll.com.au> >> 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 possibility of supporting standard >> > evaluation unquoting at the language level. This has been brought up in >> a >> > recent similar thread here [1] and on Twitter [2] where I proposed the >> > following desired (in-principle) syntax >> > >> > f <- function(col1, col2, new_col_name) { >> > mtcars %>% mutate(@new_col_name = @col1 + @col2) >> > } >> > >> > or closer to home >> > >> > x <- 1:10; y <- "x" >> > data.frame(z = @y) >> > >> > where @ would be defined as a unary prefix operator which substitutes >> the >> > quoted variable name in-place, to allow more flexibility of NSE >> functions >> > within a programming context. This mechanism exists within MySQL [3] >> (and >> > likely other languages) and could potentially be extremely useful. >> Several >> > alternatives have been incorporated into packages (most recently work >> > on tidyeval) none of which appear to fully match the simplicity of the >> > above, and some of which cut a forceful path through the syntax tree. >> > >> > The exact syntax isn't my concern at the moment (@ vs unquote() or >> other, >> > though the first requires user-supplied native prefix support within the >> > language, as per [1]) and neither is the exact way in which this would >> be >> > achieved (well above my pay grade). The practicality of @ being on the >> LHS >> > of `=` is also of a lesser concern (likely greater complexity) than the >> > RHS. >> > >> > I hear there exists (justified) reluctance to add new syntax to the >> > language, but I think this has sufficient merit (and a growing number of >> > workarounds) to warrant continued discussion. >> > >> > With kindest regards, >> > >> > - Jonathan. >> > >> > [1] https://stat.ethz.ch/pipermail/r-devel/2017-March/073894.html >> > [2] https://twitter.com/carroll_jono/status/842142292253196290 >> > [3] https://dev.mysql.com/doc/refman/5.7/en/user-variables.html >> > >> > [[alternative HTML version deleted]] >> > >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > -- > http://hadley.nz > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel