Re: [Rd] New pipe operator and gg plotz

2020-12-09 Thread Hadley Wickham
rnately, you can ask that when used in such a pipeline that the user > >> call all other arguments using names like data=whatever, > >> mapping=aes(whatever) so no other args need to be adjusted by position. > >> > >> But all this is academic and I concede wil

Re: [Rd] New pipe operator and gg plotz

2020-12-09 Thread Duncan Murdoch
g=aes(whatever) so no other args need to be adjusted by position. But all this is academic and I concede will likely not be done. I can live with the plus signs. -Original Message- From: Duncan Murdoch Sent: Sunday, December 6, 2020 2:50 PM To: Avi Gross ; 'r-devel' Subject: Re: [Rd]

Re: [Rd] New pipe operator and gg plotz

2020-12-09 Thread Greg Snow
us signs. > > > -Original Message- > From: Duncan Murdoch > Sent: Sunday, December 6, 2020 2:50 PM > To: Avi Gross ; 'r-devel' > Subject: Re: [Rd] New pipe operator and gg plotz > > Hadley's answer (#7 here: > https://community.rstudio.com/t/why-cant-ggplot2-u

Re: [Rd] New pipe operator

2020-12-09 Thread Peter Dalgaard
> On 9 Dec 2020, at 16:20 , Duncan Murdoch wrote: > > To me curry(mean, na.rm = TRUE)(x) looks a lot more complicated than mean(x, > na.rm = TRUE), especially since it has the additional risk that users can > define their own function called "curry". Not to mention that it would make

Re: [Rd] New pipe operator

2020-12-09 Thread Duncan Murdoch
On 09/12/2020 10:42 a.m., Jan van der Laan wrote: On 09-12-2020 16:20, Duncan Murdoch wrote: On 09/12/2020 9:55 a.m., Jan van der Laan wrote: I think only allowing functions on the right hand side (e.g. only the |> operator and not the |:>) would be enough to handle most cases and seems

Re: [Rd] New pipe operator

2020-12-09 Thread Jan van der Laan
On 09-12-2020 16:20, Duncan Murdoch wrote: On 09/12/2020 9:55 a.m., Jan van der Laan wrote: I think only allowing functions on the right hand side (e.g. only the |> operator and not the |:>) would be enough to handle most cases and seems easier to reason about. The limitations of that

Re: [Rd] New pipe operator

2020-12-09 Thread Duncan Murdoch
On 09/12/2020 9:55 a.m., Jan van der Laan wrote: I think only allowing functions on the right hand side (e.g. only the |> operator and not the |:>) would be enough to handle most cases and seems easier to reason about. The limitations of that can easily be worked around using existing

Re: [Rd] New pipe operator

2020-12-09 Thread Jan van der Laan
On 08-12-2020 12:46, Gabor Grothendieck wrote: Duncan Murdoch: I agree it's all about call expressions, but they aren't all being treated equally: x |> f(...) expands to f(x, ...), while x |> `function`(...) expands to `function`(...)(x). This is an exception to the rule for Yes, this

Re: [Rd] New pipe operator

2020-12-08 Thread Bravington, Mark (Data61, Hobart)
ld be great. cheers Mark Mark Bravington CSIRO Marine Lab Hobart Australia From: Duncan Murdoch Sent: Wednesday, 9 December 2020 09:28 To: Bravington, Mark (Data61, Hobart); Gabor Grothendieck; Gabriel Becker Cc: r-devel@r-project.org Subject: Re: [Rd] New pipe

Re: [Rd] New pipe operator

2020-12-08 Thread Duncan Murdoch
expr2 <- substitute( f( `_PIPE_`)) # or something... eval.parent( expr2) # or something... } Mark Bravington CSIRO Marine Lab Hobart Australia From: Duncan Murdoch Sent: Monday, 7 December 2020 21:31 To: Bravington, Mark (Data61, Hobart); Gabor Grothendieck; Gabriel Becker C

Re: [Rd] New pipe operator

2020-12-08 Thread Bravington, Mark (Data61, Hobart)
stitute( f( `_PIPE_`)) # or something... > > eval.parent( expr2) # or something... > > } Mark Bravington CSIRO Marine Lab Hobart Australia From: Duncan Murdoch Sent: Monday, 7 December 2020 21:31 To: Bravington, Mark (Data61, Hobart);

Re: [Rd] New pipe operator

2020-12-08 Thread Hadley Wickham
I just wanted to pipe in here (HA HA) to say that I agree with Kevin. I've never loved the complicated magrittr rule (which has personally tripped me up a couple of times) and I think the compact inline function syntax provides a more general solution. It is a bit more typing, and it will require

Re: [Rd] New pipe operator

2020-12-08 Thread Gabor Grothendieck
Duncan Murdoch: > I agree it's all about call expressions, but they aren't all being > treated equally: > > x |> f(...) > > expands to f(x, ...), while > > x |> `function`(...) > > expands to `function`(...)(x). This is an exception to the rule for Yes, this is the problem. It is trying to

Re: [Rd] New pipe operator

2020-12-07 Thread Gabriel Becker
Hi Denes, On Mon, Dec 7, 2020 at 2:52 PM Dénes Tóth wrote: > > > This gave me the idea that naming the arguments can be used to skip the > placeholder issue: > > "funny" |> sub(pattern = "f", replacement = "b") > > Of course this breaks if the maintainer changes the order of the > function

Re: [Rd] New pipe operator

2020-12-07 Thread Dénes Tóth
On 12/7/20 11:09 PM, Gabriel Becker wrote: On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey wrote: IMHO the use of anonymous functions is a very clean solution to the placeholder problem, and the shorthand lambda syntax makes it much more ergonomic to use. Pipe implementations that crawl the

Re: [Rd] New pipe operator

2020-12-07 Thread Gabriel Becker
On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey wrote: > IMHO the use of anonymous functions is a very clean solution to the > placeholder problem, and the shorthand lambda syntax makes it much > more ergonomic to use. Pipe implementations that crawl the RHS for > usages of `.` are going to be more

Re: [Rd] New pipe operator

2020-12-07 Thread Gabriel Becker
On Mon, Dec 7, 2020 at 10:35 AM Gabor Grothendieck wrote: > On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch > wrote: > > An advantage of the current implementation is that it's simple and easy > > to understand. Once you make it a user-modifiable binary operator, > > things will go kind of

Re: [Rd] New pipe operator

2020-12-07 Thread Gabor Grothendieck
On Mon, Dec 7, 2020 at 2:02 PM Kevin Ushey wrote: > > IMHO the use of anonymous functions is a very clean solution to the > placeholder problem, and the shorthand lambda syntax makes it much > more ergonomic to use. Pipe implementations that crawl the RHS for > usages of `.` are going to be more

Re: [Rd] New pipe operator

2020-12-07 Thread Kevin Ushey
IMHO the use of anonymous functions is a very clean solution to the placeholder problem, and the shorthand lambda syntax makes it much more ergonomic to use. Pipe implementations that crawl the RHS for usages of `.` are going to be more expensive than the alternatives. It is nice that the `|>`

Re: [Rd] New pipe operator

2020-12-07 Thread Gabor Grothendieck
On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch wrote: > An advantage of the current implementation is that it's simple and easy > to understand. Once you make it a user-modifiable binary operator, > things will go kind of nuts. > > For example, I doubt if there are many users of magrittr's pipe

Re: [Rd] New pipe operator

2020-12-07 Thread Duncan Murdoch
On 07/12/2020 12:09 p.m., 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

Re: [Rd] New pipe operator

2020-12-07 Thread Peter Dalgaard
> 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 at >> the expense of |>

Re: [Rd] New pipe operator

2020-12-07 Thread Duncan Murdoch
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 at the expense of |> head(). Just curious, how would you express head(df, 10)? Currently it

Re: [Rd] New pipe operator

2020-12-07 Thread peter dalgaard
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 at the expense of |> head(). As I think it was Gabor points out, the current structure goes down a nonstandard evaluation route, which may be

Re: [Rd] New pipe operator

2020-12-07 Thread Deepayan Sarkar
On Mon, Dec 7, 2020 at 9:23 PM Gabor Grothendieck wrote: > > One could examine how magrittr works as a reference implementation if > there is a question on how something should function. It's in > widespread use and seems to work well. Yes, but it has many inconsistencies (including for the

Re: [Rd] New pipe operator

2020-12-07 Thread Gabor Grothendieck
One could examine how magrittr works as a reference implementation if there is a question on how something should function. It's in widespread use and seems to work well. On Mon, Dec 7, 2020 at 10:20 AM Deepayan Sarkar wrote: > > On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck > wrote: > > >

Re: [Rd] New pipe operator

2020-12-07 Thread Deepayan Sarkar
On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck wrote: > > On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch > wrote: > > I agree it's all about call expressions, but they aren't all being > > treated equally: > > > > x |> f(...) > > > > expands to f(x, ...), while > > > > x |> `function`(...) >

Re: [Rd] New pipe operator

2020-12-07 Thread Gabor Grothendieck
On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch wrote: > I agree it's all about call expressions, but they aren't all being > treated equally: > > x |> f(...) > > expands to f(x, ...), while > > x |> `function`(...) > > expands to `function`(...)(x). This is an exception to the rule for > other

Re: [Rd] New pipe operator

2020-12-07 Thread Duncan Murdoch
On 06/12/2020 9:23 p.m., 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 principles. Here a similar example to the one I

Re: [Rd] New pipe operator

2020-12-07 Thread Duncan Murdoch
substitute( f( `_PIPE_`)) # or something... eval.parent( expr2) # or something... } cheers Mark Mark Bravington CSIRO Marine Lab Hobart Australia ________ From: R-devel on behalf of Gabor Grothendieck Sent: Monday, 7 December 2020 10:21 To: Gabriel Becker

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator and gg plotz

2020-12-06 Thread Avi Gross via R-devel
no other args need to be adjusted by position. But all this is academic and I concede will likely not be done. I can live with the plus signs. -Original Message- From: Duncan Murdoch Sent: Sunday, December 6, 2020 2:50 PM To: Avi Gross ; 'r-devel' Subject: Re: [Rd] New pipe operator

Re: [Rd] New pipe operator

2020-12-06 Thread Bravington, Mark (Data61, Hobart)
R-devel on behalf of Gabor Grothendieck Sent: Monday, 7 December 2020 10:21 To: Gabriel Becker Cc: r-devel@r-project.org Subject: 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 pr

Re: [Rd] New pipe operator

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

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

Re: [Rd] New pipe operator and gg plotz

2020-12-06 Thread Duncan Murdoch
ally migrate back closer to the mainstream? -Original Message- From: R-devel On Behalf Of Rui Barradas Sent: Sunday, December 6, 2020 2:51 AM To: Gregory Warnes ; Abby Spurdle Cc: r-devel Subject: Re: [Rd] New pipe operator Hello, If Hilbert liked beer, I like "pipe". M

Re: [Rd] New pipe operator and gg plotz

2020-12-06 Thread Avi Gross via R-devel
closer to the mainstream? -Original Message- From: R-devel On Behalf Of Rui Barradas Sent: Sunday, December 6, 2020 2:51 AM To: Gregory Warnes ; Abby Spurdle Cc: r-devel Subject: Re: [Rd] New pipe operator Hello, If Hilbert liked beer, I like "pipe". More seriously, a new additi

Re: [Rd] New pipe operator

2020-12-06 Thread Avi Gross via R-devel
to make things clear or we might as well code in binary. -Original Message- From: R-devel On Behalf Of Rui Barradas Sent: Sunday, December 6, 2020 2:51 AM To: Gregory Warnes ; Abby Spurdle Cc: r-devel Subject: Re: [Rd] New pipe operator Hello, If Hilbert liked beer, I like "pipe"

Re: [Rd] New pipe operator

2020-12-06 Thread Avi Gross via R-devel
art! Time to go do something useful. -Original Message- From: R-devel On Behalf Of Hiroaki Yutani Sent: Saturday, December 5, 2020 10:29 PM To: Abby Spurdle Cc: r-devel Subject: Re: [Rd] New pipe operator It is common practice to call |> as pipe (or pipeline operator) among man

Re: [Rd] New pipe operator

2020-12-05 Thread Rui Barradas
Hello, If Hilbert liked beer, I like "pipe". More seriously, a new addition like this one is going to cause problems yet unknown. But it's a good idea to have a pipe operator available. As someone used to magrittr's data pipelines, I will play with this base one before making up my mind. I

Re: [Rd] New pipe operator

2020-12-05 Thread Hiroaki Yutani
It is common practice to call |> as pipe (or pipeline operator) among many languages including ones that recently introduced it as an experimental feature. Pipeline is a common feature for functional programming, not just for "data pipeline." F#:

Re: [Rd] New pipe operator

2020-12-05 Thread Gregory Warnes
If we’re being mathematically pedantic, the “pipe” operator is actually function composition. That being said, pipes are a simple and well-known idiom. While being less than mathematically exact, it seems a reasonable label for the (very useful) behavior. On Sat, Dec 5, 2020 at 9:43 PM Abby

Re: [Rd] New pipe operator

2020-12-05 Thread Abby Spurdle
> This is a good addition I can't understand why so many people are calling this a "pipe". Pipes connect processes, via their I/O streams. Arguably, a more general interpretation would include sockets and files. https://en.wikipedia.org/wiki/Pipeline_(Unix)

Re: [Rd] New pipe operator

2020-12-05 Thread John Mount
The :: is a case that we worked to get right with wrapr dot-pipe. I shared notes on this S3/S4 pipe in the R journal https://journal.r-project.org/archive/2018/RJ-2018-042/index.html library(magrittr) packageVersion("magrittr") # [1] ‘2.0.1’ 5 %>% base::sin # Error in .::base : unused argument

Re: [Rd] New pipe operator

2020-12-05 Thread Gabor Grothendieck
The construct utils::head is not that common but bare functions are very common and to make it harder to use the common case so that the uncommon case is slightly easier is not desirable. Also it is trivial to write this which does work: mtcars %>% (utils::head) On Sat, Dec 5, 2020 at 11:59 AM

Re: [Rd] New pipe operator

2020-12-05 Thread Hugh Parsonage
I'm surprised by the aversion to mtcars |> nrow over mtcars |> nrow() and I think the decision to disallow the former should be reconsidered. The pipe operator is only going to be used when the rhs is a function, so there is no ambiguity with omitting the parentheses. If it's disallowed, it

Re: [Rd] New pipe operator

2020-12-04 Thread Duncan Murdoch
On 04/12/2020 12:06 p.m., Deepayan Sarkar wrote: On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch wrote: On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: Error: function '::' not supported in RHS call of a pipe To me, this error looks much more friendly than magrittr's error. Some of them

Re: [Rd] New pipe operator

2020-12-04 Thread Deepayan Sarkar
On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch wrote: > > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > >> Error: function '::' not supported in RHS call of a pipe > > > > To me, this error looks much more friendly than magrittr's error. > > Some of them got too used to specify functions

Re: [Rd] New pipe operator

2020-12-04 Thread Sebastian Meyer
Am 04.12.20 um 15:05 schrieb Duncan Murdoch: > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: >>>   Error: function '::' not supported in RHS call of a pipe >> >> To me, this error looks much more friendly than magrittr's error. >> Some of them got too used to specify functions without (). This >>

Re: [Rd] New pipe operator

2020-12-04 Thread Dénes Tóth
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 quite a bit more complicated.  (Maybe _

Re: [Rd] New pipe operator

2020-12-04 Thread Duncan Murdoch
On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: Error: function '::' not supported in RHS call of a pipe To me, this error looks much more friendly than magrittr's error. Some of them got too used to specify functions without (). This is OK until they use `::`, but when they need to use it,

Re: [Rd] New pipe operator

2020-12-04 Thread Hiroaki Yutani
> Error: function '::' not supported in RHS call of a pipe To me, this error looks much more friendly than magrittr's error. Some of them got too used to specify functions without (). This is OK until they use `::`, but when they need to use it, it takes hours to figure out why mtcars %>%

[Rd] New pipe operator

2020-12-04 Thread Duncan Murdoch
Just saw this on the R-devel news: R now provides a simple native pipe syntax ‘|>’ as well as a shorthand notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as ‘function(x) x + 1’. The pipe implementation as a syntax transformation was motivated by suggestions from Jim Hester and