From lawrence.michael at gene.com  Sun Mar 19 06:51:09 2017
From: lawrence.michael at gene.com (Michael Lawrence)
Date: Sat, 18 Mar 2017 22:51:09 -0700
Subject: [Rd] RFC: (in-principle) native unquoting for standard
	evaluation
In-Reply-To: <CABdHhvFsgRMN0tFZTB6q1dbS7AHDbN_+BP_SU+QXL9ap94WFfQ@mail.gmail.com>
References: <CAAjDRii1dPxNMTn9TSgReooOry2omQg9GCmXYDDFc99qv=F+7A@mail.gmail.com>
	<CAOQ5NydWHiqHkTVc=DHiQgqVkVqnoUN35EZYyQTwMJCWkap42A@mail.gmail.com>
	<CABdHhvFsgRMN0tFZTB6q1dbS7AHDbN_+BP_SU+QXL9ap94WFfQ@mail.gmail.com>
Message-ID: <CAOQ5NyeF8fDYGwES0sy5eQfgFriK4Hos7vqX9R2YxkLgTPrhmg@mail.gmail.com>

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.

Michael


On Sat, Mar 18, 2017 at 7:39 PM, Hadley Wickham <h.wickham at 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.michael at 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 <jono at 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 at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> http://hadley.nz



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