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

2017-03-18 Thread Michael Lawrence
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 m

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

2017-03-18 Thread Jonathan Carroll
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_ev

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

2017-03-18 Thread Hadley Wickham
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: > Interesting idea. Lazy and non-stand

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

2017-03-18 Thread Hadley Wickham
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 possibility of supporting s

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

2017-03-18 Thread John Mount
Obviously we have to be sensitive about language and parser changes. However, I think Jonathan Carroll has identified a feature that is well understood in the Lisp world (quoting and unquoting) that is missing from the R language. Some symbol that indirects to a value (only once!, we don’t wan

Re: [Rd] Experimental CXX_STD problem in R 3.4

2017-03-18 Thread Dirk Eddelbuettel
On 18 March 2017 at 14:21, Jeroen Ooms wrote: | R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 | / CXX14 / CXX17. R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I would only refer to the CXX17 part as experimental. | However on most platforms, the

[Rd] Experimental CXX_STD problem in R 3.4

2017-03-18 Thread Jeroen Ooms
R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 / CXX14 / CXX17. However on most platforms, the R configuration seems to leave the CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather than falling back on default CXX). Therefore specifying e.g CXX_STD= CXX14 will