[Rd] Experimental CXX_STD problem in R 3.4

[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 fail build with cryptic errors (due to compiling with CXX="")

I don't think this is intended? Some examples from r-devel on Windows:

CXX11: https://win-builder.r-project.org/R8gg703OQSq5/
CXX98: https://win-builder.r-project.org/mpVfXxk79FaN/
CXX14: https://win-builder.r-project.org/L3BSMgAk4cQ7/
CXX17: https://win-builder.r-project.org/3ETZXrgkg77I/

Similar problems appear on Linux. I think the problem is that Makeconf
contains e.g:

CXX1Z =
CXX1ZFLAGS =
CXX1ZPICFLAGS =
CXX1ZSTD =

When CXX_STD contains any other unsupported value (e.g. CXX24) R
simply falls back on the default CXX configuration. The same should
probably happen for e.g. CXX17 when CXX1Z is unset in Makeconf?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Experimental CXX_STD problem in R 3.4

[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 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 fail build with cryptic errors (due to compiling with CXX="")

That depends of course on the compiler found on the system. On my box (with
g++ being g++-6.2 which _defaults_ to C++14) all is well up to CXX1Y.

But I also have CXX1Z empty. 
 
| I don't think this is intended? Some examples from r-devel on Windows:
| 
| CXX11: https://win-builder.r-project.org/R8gg703OQSq5/
| CXX98: https://win-builder.r-project.org/mpVfXxk79FaN/
| CXX14: https://win-builder.r-project.org/L3BSMgAk4cQ7/
| CXX17: https://win-builder.r-project.org/3ETZXrgkg77I/

You can't expect CXX14 and CXX17 to work with the only available compiler
there, g++-4.9.3.
 
| Similar problems appear on Linux. I think the problem is that Makeconf
| contains e.g:
| 
| CXX1Z =
| CXX1ZFLAGS =
| CXX1ZPICFLAGS =
| CXX1ZSTD =
| 
| When CXX_STD contains any other unsupported value (e.g. CXX24) R
| simply falls back on the default CXX configuration. The same should
| probably happen for e.g. CXX17 when CXX1Z is unset in Makeconf?

Probably.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[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 want this chaining; 
and there are issues of quoting it out) in eval would be very valuable.  
Obviously it is most useful where non-standard evaluation is emphasized 
(plotting, formulas, and dplyr being the examples that I can immediately think 
of).

---
John Mount
http://www.win-vector.com/  
Our book: Practical Data Science with R 
https://www.manning.com/books/practical-data-science-with-r 
 




[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

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


-- 
http://hadley.nz

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

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

[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_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  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 
> 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 
>> 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

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

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel