Re: [Rd] New pipe operator

This is really irrelevant. On Sun, Dec 6, 2020 at 9:23 PM Gabriel Becker wrote: > > Hi Gabor, > > On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck > wrote: >> >> I understand very well that it is implemented at the syntax level; >> however, in any case the implementation is irrelevant to the p

Re: [Rd] New pipe operator

Hi Gabor, On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck wrote: > I understand very well that it is implemented at the syntax level; > however, in any case the implementation is irrelevant to the principles. > > Here a similar example to the one I gave before but this time written out: > > Th

Re: [Rd] New pipe operator and gg plotz

Thanks, Duncan. That answers my question fairly definitively. Although it can be DONE it likely won't be for the reasons Hadley mentioned until we get some other product that replaces it entirely. There are some interesting work-arounds mentioned. I was thinking of one that has overhead but mi

Re: [Rd] New pipe operator

Seems like this *could* be a good thing, and thanks to R core for considering it. But, FWIW: - I agree with Gabor G that consistency of "syntax" should be paramount here. Enough problems have been caused by earlier superficially-convenient non-standard features in R. In particular: -- there

Re: [Rd] New pipe operator

I understand very well that it is implemented at the syntax level; however, in any case the implementation is irrelevant to the principles. Here a similar example to the one I gave before but this time written out: This works: 3 |> function(x) x + 1 but this does not: foo <- function(x) x

Re: [Rd] New pipe operator

Hi Gabor, On Sun, Dec 6, 2020 at 12:52 PM Gabor Grothendieck wrote: > I think the real issue here is that functions are supposed to be > first class objects in R > or are supposed to be and |> would break that if if is possible > to write function(x) x + 1 on the RHS but not foo (assuming foo >

Re: [Rd] New pipe operator

I think the real issue here is that functions are supposed to be first class objects in R or are supposed to be and |> would break that if if is possible to write function(x) x + 1 on the RHS but not foo (assuming foo was defined as that function). I don't think getting experience with using it ca

Re: [Rd] [External] Re: New pipe operator

Hi Gabriel, Thanks for the comments. See inline. On 12/6/20 8:16 PM, Gabriel Becker wrote: Hi Denes, On Sun, Dec 6, 2020 at 6:43 AM Dénes Tóth > wrote: Dear Luke, In the meantime I checked the R-syntax branch and the docs; they are very helpful. I

Re: [Rd] New pipe operator and gg plotz

Hadley's answer (#7 here: https://community.rstudio.com/t/why-cant-ggplot2-use/4372) makes it pretty clear that he thinks it would have been nice now if he had made that choice when ggplot2 came out, but it's not worth the effort now to change it. Duncan Murdoch On 06/12/2020 2:34 p.m., Avi

Re: [Rd] New pipe operator and gg plotz

As someone who switches back and forth between using standard R methods and those of the tidyverse, depending on the problem, my mood and whether Jupiter aligns with Saturn in the new age of Aquarius, I have a question about the forthcoming built-in pipe. Will it motivate anyone to eventually ch

Re: [Rd] [External] Re: New pipe operator

Hi Denes, On Sun, Dec 6, 2020 at 6:43 AM Dénes Tóth wrote: > Dear Luke, > > In the meantime I checked the R-syntax branch and the docs; they are > very helpful. I would also like to thank you for putting effort into > this feature. Keeping it at the syntax level is also a very smart > decision.

Re: [Rd] [External] Re: New pipe operator

On Sun, 6 Dec 2020, Gabor Grothendieck wrote: Why is that ambiguous? It works in magrittr. For now, all functions marked internally as syntactically special are disallowed. Not all of these lead to ambiguities. Best, luke library(magrittr) 1 %>% `+`() [1] 1 On Sun, Dec 6, 2020 at 1:09

Re: [Rd] New pipe operator

Topic is more about anonymous functions but also pipes. Rui thought the proposed syntax was a bit ugly. I assume the \(x) ... was what he means, not the function(x)... version. Many current languages have played games on adding some form of anonymous function that is defined and used in place.

Re: [Rd] [External] Re: New pipe operator

Why is that ambiguous? It works in magrittr. > library(magrittr) > 1 %>% `+`() [1] 1 On Sun, Dec 6, 2020 at 1:09 PM wrote: > > On Sun, 6 Dec 2020, Gabor Grothendieck wrote: > > > The following gives an error. > > > > 1 |> `+`(2) > > ## Error: function '+' is not supported in RHS call of a p

Re: [Rd] [External] Re: New pipe operator

On Sun, 6 Dec 2020, Gabor Grothendieck wrote: The following gives an error. 1 |> `+`(2) ## Error: function '+' is not supported in RHS call of a pipe 1 |> `+`() ## Error: function '+' is not supported in RHS call of a pipe but this does work: 1 |> (`+`)(2) ## [1] 3 1 |> (`+`)(

Re: [Rd] [External] Re: New pipe operator

The following gives an error. 1 |> `+`(2) ## Error: function '+' is not supported in RHS call of a pipe 1 |> `+`() ## Error: function '+' is not supported in RHS call of a pipe but this does work: 1 |> (`+`)(2) ## [1] 3 1 |> (`+`)() ## [1] 1 The error message suggests

Re: [Rd] [External] Re: New pipe operator

On 06/12/2020 11:34 a.m., Dénes Tóth wrote: On 12/6/20 4:32 PM, Duncan Murdoch wrote: > On 06/12/2020 9:43 a.m., Dénes Tóth wrote: >> Dear Luke, >> >> In the meantime I checked the R-syntax branch and the docs; they are >> very helpful. I would also like to thank you for putting effor

Re: [Rd] [External] Re: New pipe operator

On 12/6/20 4:32 PM, Duncan Murdoch wrote: > On 06/12/2020 9:43 a.m., Dénes Tóth wrote: >> Dear Luke, >> >> In the meantime I checked the R-syntax branch and the docs; they are >> very helpful. I would also like to thank you for putting effort into >> this feature. Keeping it at the syntax level

Re: [Rd] [External] Re: New pipe operator

On 06/12/2020 9:43 a.m., Dénes Tóth wrote: Dear Luke, In the meantime I checked the R-syntax branch and the docs; they are very helpful. I would also like to thank you for putting effort into this feature. Keeping it at the syntax level is also a very smart decision. However, the current API mig

Re: [Rd] New pipe operator

Naming is another whole topic. I have seen suggestions that the current pipeline symbol used be phrased as THEN so data %>% f1 %>% f2() would be said as something like: take data then apply f1 then f2 or some variants. There are words other than pipe or pipeline that might also work such as

Re: [Rd] installling R-devel on Windows

I meant on the R devel download page. (I was just installing Rtools40 on another computer.) On Sun, Dec 6, 2020 at 10:27 AM Gabor Grothendieck wrote: > > I tried it from another computer and it did work. Is there some way > of installing R devel using the analog of the R --vanilla flag so that I

Re: [Rd] installling R-devel on Windows

I tried it from another computer and it did work. Is there some way of installing R devel using the analog of the R --vanilla flag so that I can do it in a reproducible manner. It seems to remember prior settings and maybe that is a problem although one would not expect a setting that could lead t

Re: [Rd] as.POSIXct.numeric change default of origin argument

For example, this works: library(zoo) as.Date(0) ## [1] "1970-01-01" On Sun, Dec 6, 2020 at 7:10 AM Achim Zeileis wrote: > > On Sun, 6 Dec 2020, Jan Gorecki wrote: > > > Hello all, > > > > I would like to propose to change the default value for "origin" > > argument in as.POSIXct.numeric m

Re: [Rd] [External] Re: New pipe operator

Dear Luke, In the meantime I checked the R-syntax branch and the docs; they are very helpful. I would also like to thank you for putting effort into this feature. Keeping it at the syntax level is also a very smart decision. However, the current API might not exploit the full power of the bas

Re: [Rd] as.POSIXct.numeric change default of origin argument

On Sun, 6 Dec 2020, Jan Gorecki wrote: Hello all, I would like to propose to change the default value for "origin" argument in as.POSIXct.numeric method, from current missing to new "1970-01-01". My proposal is motivated by the fact that this is the most commonly needed value for "origin" argum

Re: [Rd] as.POSIXct.numeric change default of origin argument

The fda package already includes as.POSIXct1970, which also sets tz="GMT" by default. I made the equivalent thing for as.Date available as "Ecfun::as.Date1970". If the Core R team doesn't want to make the change for the existing functions, they might consider adding alternatives l

[Rd] as.POSIXct.numeric change default of origin argument

Hello all, I would like to propose to change the default value for "origin" argument in as.POSIXct.numeric method, from current missing to new "1970-01-01". My proposal is motivated by the fact that this is the most commonly needed value for "origin" argument and having that as a default seems rea

Re: [Rd] [External] Re: New pipe operator

Luke, When writing a blog post on that, could you please describe performance implications that this new feature will carry? AFAIU, compared to a standard way of using temporary variables, pipes will allow to not increment REFCNT of objects being piped into. Therefore peak memory usage could be low