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

2020-12-09 Thread Gabor Grothendieck
On Wed, Dec 9, 2020 at 12:36 PM Gabriel Becker wrote: > I mean, I think the bizarro pipe was a pretty clever piece of work. I was > impressed by what John did there, but I don't really know what you're > suggesting here. As you say, the bizarro pipe works now without any changes > and you're

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

2020-12-09 Thread Gabriel Becker
On Wed, Dec 9, 2020 at 8:26 AM Gabor Grothendieck wrote: > On Wed, Dec 9, 2020 at 10:08 AM Duncan Murdoch > wrote: > > > > You might be interested in this blog post by Michael Barrowman: > > > > https://michaelbarrowman.co.uk/post/the-new-base-pipe/ > > > > He does some timing comparisons, and

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

2020-12-09 Thread Gabor Grothendieck
On Wed, Dec 9, 2020 at 10:08 AM Duncan Murdoch wrote: > > You might be interested in this blog post by Michael Barrowman: > > https://michaelbarrowman.co.uk/post/the-new-base-pipe/ > > He does some timing comparisons, and the current R-devel implementations > of |> and \() do quite well. It does

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

2020-12-09 Thread Duncan Murdoch
You might be interested in this blog post by Michael Barrowman: https://michaelbarrowman.co.uk/post/the-new-base-pipe/ He does some timing comparisons, and the current R-devel implementations of |> and \() do quite well. Duncan Murdoch On 06/12/2020 4:42 a.m., Jan Gorecki wrote: Luke,

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

2020-12-08 Thread Gabor Grothendieck
On Mon, Dec 7, 2020 at 9:09 AM Gabor Grothendieck wrote: > > On Sat, Dec 5, 2020 at 1:19 PM wrote: > > Let's get some experience > > Here is my last SO post using dplyr rewritten to use R 4.1 devel. Seems It occurred to me it would also be interesting to show this example rewritten using John

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

2020-12-07 Thread luke-tierney
On Mon, 7 Dec 2020, Peter Dalgaard wrote: On 7 Dec 2020, at 17:35 , Duncan Murdoch wrote: On 07/12/2020 11:18 a.m., peter dalgaard wrote: Hmm, I feel a bit bad coming late to this, but I think I am beginning to side with those who want "... |> head" to work. And yes, that has to happen

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

2020-12-07 Thread Duncan Murdoch
On 07/12/2020 12:03 p.m., Gregory Warnes wrote: My vote is for the consistency of function calls always having parentheses, including in pipes. Making them optional only saves two keystrokes, but will add yet another inconsistency to confuse or trip folks up. As for the new anonymous function

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

2020-12-07 Thread Gregory Warnes
My vote is for the consistency of function calls always having parentheses, including in pipes. Making them optional only saves two keystrokes, but will add yet another inconsistency to confuse or trip folks up. As for the new anonymous function syntax, I would prefer something more human

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

2020-12-07 Thread Gabor Grothendieck
On Mon, Dec 7, 2020 at 10:11 AM wrote: > Or, keeping dplyr but with R-devel pipe and function shorthand: > > DF <- "myfile.csv" %>% > readLines() |> > \(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |> > \(.) read.csv(text = .) |> > mutate(across(2:3, \(col) lapply(col, \(x)

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

2020-12-07 Thread luke-tierney
Or, keeping dplyr but with R-devel pipe and function shorthand: DF <- "myfile.csv" %>% readLines() |> \(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |> \(.) read.csv(text = .) |> mutate(across(2:3, \(col) lapply(col, \(x) eval(parse(text = x) Using named arguments to

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

2020-12-07 Thread Gabor Grothendieck
On Sat, Dec 5, 2020 at 1:19 PM wrote: > Let's get some experience Here is my last SO post using dplyr rewritten to use R 4.1 devel. Seems not too bad. Was able to work around the placeholder for gsub by specifying the arg names and used \(...)... elsewhere. This does not address the

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

2020-12-06 Thread Dénes Tóth
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] [External] Re: New pipe operator

2020-12-06 Thread Gabriel Becker
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

2020-12-06 Thread luke-tierney
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

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

2020-12-06 Thread Gabor Grothendieck
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

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

2020-12-06 Thread luke-tierney
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

2020-12-06 Thread Gabor Grothendieck
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

2020-12-06 Thread Duncan Murdoch
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

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

2020-12-06 Thread Dénes Tóth
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

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

2020-12-06 Thread Duncan Murdoch
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

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

2020-12-06 Thread Dénes Tóth
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

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

2020-12-06 Thread Jan Gorecki
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

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

2020-12-05 Thread luke-tierney
We went back and forth on this several times. The key advantage of requiring parentheses is to keep things simple and consistent. Let's get some experience with that. If experience shows requiring parentheses creates too many issues then we can add the option of dropping them later (with special

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

2020-12-05 Thread Duncan Murdoch
On 04/12/2020 9:11 p.m., luke-tier...@uiowa.edu wrote: On Sat, 5 Dec 2020, Duncan Murdoch wrote: On 04/12/2020 2:26 p.m., luke-tier...@uiowa.edu wrote: On Fri, 4 Dec 2020, Dénes Tóth wrote: On 12/4/20 3:05 PM, Duncan Murdoch wrote: ... It's tempting to suggest it should allow something

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

2020-12-05 Thread Avi Gross via R-devel
uot; feels better in the new version as "|>" has the UNIX pipe symbol "|" in it. -Original Message- From: R-devel On Behalf Of luke-tier...@uiowa.edu Sent: Friday, December 4, 2020 9:11 PM To: Duncan Murdoch Cc: r-devel@r-project.org Subject: Re: [Rd] [External]

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

2020-12-04 Thread Ivan Krylov
On Fri, 4 Dec 2020 20:11:17 -0600 (CST) luke-tier...@uiowa.edu wrote: > We did try a number of variations; the code is in the R-syntax branch. > At the root of that branch are two .md files with some notes as of > around useR20. Thanks for the information! Can I make a suggestion? If the

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

2020-12-04 Thread luke-tierney
On Sat, 5 Dec 2020, Duncan Murdoch wrote: On 04/12/2020 2:26 p.m., luke-tier...@uiowa.edu wrote: On Fri, 4 Dec 2020, Dénes Tóth wrote: On 12/4/20 3:05 PM, Duncan Murdoch wrote: ... It's tempting to suggest it should allow something like   mtcars |> subset(cyl == 4) |> lm(mpg ~ disp,

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

2020-12-04 Thread Duncan Murdoch
On 04/12/2020 2:26 p.m., luke-tier...@uiowa.edu wrote: On Fri, 4 Dec 2020, Dénes Tóth wrote: On 12/4/20 3:05 PM, Duncan Murdoch wrote: ... It's tempting to suggest it should allow something like   mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) which would be expanded to

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

2020-12-04 Thread luke-tierney
On Fri, 4 Dec 2020, Dénes Tóth wrote: On 12/4/20 3:05 PM, Duncan Murdoch wrote: ... It's tempting to suggest it should allow something like   mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) which would be expanded to something equivalent to the other versions: but that makes it