Re: New pipe operator and gg plotz

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

R devel mailing list
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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?

I mean I now sometimes have a pipeline that looks like:

Data %>%
        Do_this %>%
        Do_that(whatever) %>%
        ggplot(...) +
                geom_whatever(...) +
                ...

My understanding is this is a bit of a historical anomaly that might someday be modified back.

As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.

So the above silly example might become:

Data %>%
        Do_this %>%
        Do_that(whatever) %>%
        ggplot(...) %>%
        geom_whatever(...) %>%
        ...

Or, am I missing something here?

The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?

-----Original Message-----
From: R-devel <[hidden email]> On Behalf Of Rui Barradas
Sent: Sunday, December 6, 2020 2:51 AM
To: Gregory Warnes <[hidden email]>; Abby Spurdle <[hidden email]>
Cc: r-devel <[hidden email]>
Subject: Re: [Rd] New pipe operator

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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?

Hope this helps,

Rui Barradas


Às 03:22 de 06/12/20, Gregory Warnes escreveu:

> 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 Spurdle <[hidden email]> wrote:
>
>>> 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)
>> https://en.wikipedia.org/wiki/Named_pipe
>> https://en.wikipedia.org/wiki/Anonymous_pipe
>>
>> As far as I can tell, the magrittr-like operators are functions (not
>> pipes), with nonstandard syntax.
>> This is not consistent with R's original design philosophy, building
>> on C, Lisp and S, along with lots of *important* math and stats.
>>
>> It's possible that some parties are interested in creating a kind of
>> "data pipeline".
>> I'm interested in this myself, and I think we could discuss this more.
>> But I'm not convinced the magrittr-like operators help to achieve
>> this goal.
>> Which, in my opinion, would require one to model programs as directed
>> graphs, along with some degree of asynchronous input.
>>
>> Presumably, these operators will be added to R anyway, and (almost)
>> no one will listen to me.
>>
>> So, I would like to make one suggestion:
>> Is it possible for these operators to *not* be named:
>>      The R Pipe
>>      The S Pipe
>>      Or anything with a similar meaning.
>>
>> Maybe tidy pipe, or something else that links it to its proponents?
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Scanned by McAfee and confirmed virus-free.
Find out more here: https://bit.ly/2zCJMrO

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

Duncan Murdoch-2
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 Gross via R-devel wrote:

> 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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?
>
> I mean I now sometimes have a pipeline that looks like:
>
> Data %>%
> Do_this %>%
> Do_that(whatever) %>%
> ggplot(...) +
> geom_whatever(...) +
> ...
>
> My understanding is this is a bit of a historical anomaly that might someday be modified back.
>
> As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.
>
> So the above silly example might become:
>
> Data %>%
> Do_this %>%
> Do_that(whatever) %>%
> ggplot(...) %>%
> geom_whatever(...) %>%
> ...
>
> Or, am I missing something here?
>
> The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?
>
> -----Original Message-----
> From: R-devel <[hidden email]> On Behalf Of Rui Barradas
> Sent: Sunday, December 6, 2020 2:51 AM
> To: Gregory Warnes <[hidden email]>; Abby Spurdle <[hidden email]>
> Cc: r-devel <[hidden email]>
> Subject: Re: [Rd] New pipe operator
>
> 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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
> As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
>
> Hope this helps,
>
> Rui Barradas
>
>
> Às 03:22 de 06/12/20, Gregory Warnes escreveu:
>> 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 Spurdle <[hidden email]> wrote:
>>
>>>> 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)
>>> https://en.wikipedia.org/wiki/Named_pipe
>>> https://en.wikipedia.org/wiki/Anonymous_pipe
>>>
>>> As far as I can tell, the magrittr-like operators are functions (not
>>> pipes), with nonstandard syntax.
>>> This is not consistent with R's original design philosophy, building
>>> on C, Lisp and S, along with lots of *important* math and stats.
>>>
>>> It's possible that some parties are interested in creating a kind of
>>> "data pipeline".
>>> I'm interested in this myself, and I think we could discuss this more.
>>> But I'm not convinced the magrittr-like operators help to achieve
>>> this goal.
>>> Which, in my opinion, would require one to model programs as directed
>>> graphs, along with some degree of asynchronous input.
>>>
>>> Presumably, these operators will be added to R anyway, and (almost)
>>> no one will listen to me.
>>>
>>> So, I would like to make one suggestion:
>>> Is it possible for these operators to *not* be named:
>>>       The R Pipe
>>>       The S Pipe
>>>       Or anything with a similar meaning.
>>>
>>> Maybe tidy pipe, or something else that links it to its proponents?
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> Scanned by McAfee and confirmed virus-free.
> Find out more here: https://bit.ly/2zCJMrO
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

R devel mailing list
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 might be a pain. Hadley mentioned a slight variant. The first argument to a function now is expected to be the data argument. The second might be the mapping. Now if the function is called with a new first argument that is a ggplot object, it could be possible to test the type and if it is a ggplot object than slide over carefully any additional matched arguments that were not explicitly named. Not sure that is at all easy to do.

Alternately, 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 will likely not be done. I can live with the plus signs.


-----Original Message-----
From: Duncan Murdoch <[hidden email]>
Sent: Sunday, December 6, 2020 2:50 PM
To: Avi Gross <[hidden email]>; 'r-devel' <[hidden email]>
Subject: 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 Gross via R-devel wrote:

> 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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?
>
> I mean I now sometimes have a pipeline that looks like:
>
> Data %>%
> Do_this %>%
> Do_that(whatever) %>%
> ggplot(...) +
> geom_whatever(...) +
> ...
>
> My understanding is this is a bit of a historical anomaly that might someday be modified back.
>
> As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.
>
> So the above silly example might become:
>
> Data %>%
> Do_this %>%
> Do_that(whatever) %>%
> ggplot(...) %>%
> geom_whatever(...) %>%
> ...
>
> Or, am I missing something here?
>
> The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?
>
> -----Original Message-----
> From: R-devel <[hidden email]> On Behalf Of Rui
> Barradas
> Sent: Sunday, December 6, 2020 2:51 AM
> To: Gregory Warnes <[hidden email]>; Abby Spurdle
> <[hidden email]>
> Cc: r-devel <[hidden email]>
> Subject: Re: [Rd] New pipe operator
>
> 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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
> As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
>
> Hope this helps,
>
> Rui Barradas
>
>
> Às 03:22 de 06/12/20, Gregory Warnes escreveu:
>> 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 Spurdle <[hidden email]> wrote:
>>
>>>> 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)
>>> https://en.wikipedia.org/wiki/Named_pipe
>>> https://en.wikipedia.org/wiki/Anonymous_pipe
>>>
>>> As far as I can tell, the magrittr-like operators are functions (not
>>> pipes), with nonstandard syntax.
>>> This is not consistent with R's original design philosophy, building
>>> on C, Lisp and S, along with lots of *important* math and stats.
>>>
>>> It's possible that some parties are interested in creating a kind of
>>> "data pipeline".
>>> I'm interested in this myself, and I think we could discuss this more.
>>> But I'm not convinced the magrittr-like operators help to achieve
>>> this goal.
>>> Which, in my opinion, would require one to model programs as
>>> directed graphs, along with some degree of asynchronous input.
>>>
>>> Presumably, these operators will be added to R anyway, and (almost)
>>> no one will listen to me.
>>>
>>> So, I would like to make one suggestion:
>>> Is it possible for these operators to *not* be named:
>>>       The R Pipe
>>>       The S Pipe
>>>       Or anything with a similar meaning.
>>>
>>> Maybe tidy pipe, or something else that links it to its proponents?
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> Scanned by McAfee and confirmed virus-free.
> Find out more here: https://bit.ly/2zCJMrO
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

glsnow
Since `+` is already a function we could do regular piping to change this code:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) +
  geom_point()

to this:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) %>%
  `+`(geom_point())

Further we can write wrapper functions like:

p_geom_point <- function(x,...) {
  x + geom_point(...)
}

The run the code like:

mtcars %>%
  ggplot(aes(x=wt, y=mpg)) %>%
  p_geom_point()

All three of the above give the same plot from what I can see, but I
have not tested it with very many options beyond the above.

A really ambitious person could create a new package with wrappers for
all the ggplot2 functions that can come after the plus sign, then we
could use pipes for everything.  I don't know if there are any strange
circumstances that would make this cause problems (it probably will
slow things down slightly, but probably not enough for people to
notice).

On Sun, Dec 6, 2020 at 7:18 PM Avi Gross via R-devel
<[hidden email]> wrote:

>
> 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 might be a pain. Hadley mentioned a slight variant. The first argument to a function now is expected to be the data argument. The second might be the mapping. Now if the function is called with a new first argument that is a ggplot object, it could be possible to test the type and if it is a ggplot object than slide over carefully any additional matched arguments that were not explicitly named. Not sure that is at all easy to do.
>
> Alternately, 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 will likely not be done. I can live with the plus signs.
>
>
> -----Original Message-----
> From: Duncan Murdoch <[hidden email]>
> Sent: Sunday, December 6, 2020 2:50 PM
> To: Avi Gross <[hidden email]>; 'r-devel' <[hidden email]>
> Subject: 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 Gross via R-devel wrote:
> > 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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?
> >
> > I mean I now sometimes have a pipeline that looks like:
> >
> > Data %>%
> >       Do_this %>%
> >       Do_that(whatever) %>%
> >       ggplot(...) +
> >               geom_whatever(...) +
> >               ...
> >
> > My understanding is this is a bit of a historical anomaly that might someday be modified back.
> >
> > As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.
> >
> > So the above silly example might become:
> >
> > Data %>%
> >       Do_this %>%
> >       Do_that(whatever) %>%
> >       ggplot(...) %>%
> >       geom_whatever(...) %>%
> >       ...
> >
> > Or, am I missing something here?
> >
> > The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?
> >
> > -----Original Message-----
> > From: R-devel <[hidden email]> On Behalf Of Rui
> > Barradas
> > Sent: Sunday, December 6, 2020 2:51 AM
> > To: Gregory Warnes <[hidden email]>; Abby Spurdle
> > <[hidden email]>
> > Cc: r-devel <[hidden email]>
> > Subject: Re: [Rd] New pipe operator
> >
> > 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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
> > As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
> >
> > Hope this helps,
> >
> > Rui Barradas
> >
> >
> > Às 03:22 de 06/12/20, Gregory Warnes escreveu:
> >> 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 Spurdle <[hidden email]> wrote:
> >>
> >>>> 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)
> >>> https://en.wikipedia.org/wiki/Named_pipe
> >>> https://en.wikipedia.org/wiki/Anonymous_pipe
> >>>
> >>> As far as I can tell, the magrittr-like operators are functions (not
> >>> pipes), with nonstandard syntax.
> >>> This is not consistent with R's original design philosophy, building
> >>> on C, Lisp and S, along with lots of *important* math and stats.
> >>>
> >>> It's possible that some parties are interested in creating a kind of
> >>> "data pipeline".
> >>> I'm interested in this myself, and I think we could discuss this more.
> >>> But I'm not convinced the magrittr-like operators help to achieve
> >>> this goal.
> >>> Which, in my opinion, would require one to model programs as
> >>> directed graphs, along with some degree of asynchronous input.
> >>>
> >>> Presumably, these operators will be added to R anyway, and (almost)
> >>> no one will listen to me.
> >>>
> >>> So, I would like to make one suggestion:
> >>> Is it possible for these operators to *not* be named:
> >>>       The R Pipe
> >>>       The S Pipe
> >>>       Or anything with a similar meaning.
> >>>
> >>> Maybe tidy pipe, or something else that links it to its proponents?
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> > Scanned by McAfee and confirmed virus-free.
> > Find out more here: https://bit.ly/2zCJMrO
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



--
Gregory (Greg) L. Snow Ph.D.
[hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

Duncan Murdoch-2
Looks like Sergio Oller took your ambitious approach:
https://github.com/zeehio/ggpipe.  It hasn't been updated since 2017, so
there may be some new things in ggplot2 that aren't there yet.

Duncan Murdoch

On 09/12/2020 2:16 p.m., Greg Snow wrote:

> Since `+` is already a function we could do regular piping to change this code:
>
> mtcars %>%
>    ggplot(aes(x=wt, y=mpg)) +
>    geom_point()
>
> to this:
>
> mtcars %>%
>    ggplot(aes(x=wt, y=mpg)) %>%
>    `+`(geom_point())
>
> Further we can write wrapper functions like:
>
> p_geom_point <- function(x,...) {
>    x + geom_point(...)
> }
>
> The run the code like:
>
> mtcars %>%
>    ggplot(aes(x=wt, y=mpg)) %>%
>    p_geom_point()
>
> All three of the above give the same plot from what I can see, but I
> have not tested it with very many options beyond the above.
>
> A really ambitious person could create a new package with wrappers for
> all the ggplot2 functions that can come after the plus sign, then we
> could use pipes for everything.  I don't know if there are any strange
> circumstances that would make this cause problems (it probably will
> slow things down slightly, but probably not enough for people to
> notice).
>
> On Sun, Dec 6, 2020 at 7:18 PM Avi Gross via R-devel
> <[hidden email]> wrote:
>>
>> 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 might be a pain. Hadley mentioned a slight variant. The first argument to a function now is expected to be the data argument. The second might be the mapping. Now if the function is called with a new first argument that is a ggplot object, it could be possible to test the type and if it is a ggplot object than slide over carefully any additional matched arguments that were not explicitly named. Not sure that is at all easy to do.
>>
>> Alternately, 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 will likely not be done. I can live with the plus signs.
>>
>>
>> -----Original Message-----
>> From: Duncan Murdoch <[hidden email]>
>> Sent: Sunday, December 6, 2020 2:50 PM
>> To: Avi Gross <[hidden email]>; 'r-devel' <[hidden email]>
>> Subject: 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 Gross via R-devel wrote:
>>> 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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?
>>>
>>> I mean I now sometimes have a pipeline that looks like:
>>>
>>> Data %>%
>>>        Do_this %>%
>>>        Do_that(whatever) %>%
>>>        ggplot(...) +
>>>                geom_whatever(...) +
>>>                ...
>>>
>>> My understanding is this is a bit of a historical anomaly that might someday be modified back.
>>>
>>> As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.
>>>
>>> So the above silly example might become:
>>>
>>> Data %>%
>>>        Do_this %>%
>>>        Do_that(whatever) %>%
>>>        ggplot(...) %>%
>>>        geom_whatever(...) %>%
>>>        ...
>>>
>>> Or, am I missing something here?
>>>
>>> The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?
>>>
>>> -----Original Message-----
>>> From: R-devel <[hidden email]> On Behalf Of Rui
>>> Barradas
>>> Sent: Sunday, December 6, 2020 2:51 AM
>>> To: Gregory Warnes <[hidden email]>; Abby Spurdle
>>> <[hidden email]>
>>> Cc: r-devel <[hidden email]>
>>> Subject: Re: [Rd] New pipe operator
>>>
>>> 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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
>>> As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
>>>
>>> Hope this helps,
>>>
>>> Rui Barradas
>>>
>>>
>>> Às 03:22 de 06/12/20, Gregory Warnes escreveu:
>>>> 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 Spurdle <[hidden email]> wrote:
>>>>
>>>>>> 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)
>>>>> https://en.wikipedia.org/wiki/Named_pipe
>>>>> https://en.wikipedia.org/wiki/Anonymous_pipe
>>>>>
>>>>> As far as I can tell, the magrittr-like operators are functions (not
>>>>> pipes), with nonstandard syntax.
>>>>> This is not consistent with R's original design philosophy, building
>>>>> on C, Lisp and S, along with lots of *important* math and stats.
>>>>>
>>>>> It's possible that some parties are interested in creating a kind of
>>>>> "data pipeline".
>>>>> I'm interested in this myself, and I think we could discuss this more.
>>>>> But I'm not convinced the magrittr-like operators help to achieve
>>>>> this goal.
>>>>> Which, in my opinion, would require one to model programs as
>>>>> directed graphs, along with some degree of asynchronous input.
>>>>>
>>>>> Presumably, these operators will be added to R anyway, and (almost)
>>>>> no one will listen to me.
>>>>>
>>>>> So, I would like to make one suggestion:
>>>>> Is it possible for these operators to *not* be named:
>>>>>        The R Pipe
>>>>>        The S Pipe
>>>>>        Or anything with a similar meaning.
>>>>>
>>>>> Maybe tidy pipe, or something else that links it to its proponents?
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>> Scanned by McAfee and confirmed virus-free.
>>> Find out more here: https://bit.ly/2zCJMrO
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: New pipe operator and gg plotz

hadley wickham
Another option is https://github.com/hadley/ggplot1 🤣
Hadley

On Wed, Dec 9, 2020 at 1:24 PM Duncan Murdoch <[hidden email]> wrote:

>
> Looks like Sergio Oller took your ambitious approach:
> https://github.com/zeehio/ggpipe.  It hasn't been updated since 2017, so
> there may be some new things in ggplot2 that aren't there yet.
>
> Duncan Murdoch
>
> On 09/12/2020 2:16 p.m., Greg Snow wrote:
> > Since `+` is already a function we could do regular piping to change this code:
> >
> > mtcars %>%
> >    ggplot(aes(x=wt, y=mpg)) +
> >    geom_point()
> >
> > to this:
> >
> > mtcars %>%
> >    ggplot(aes(x=wt, y=mpg)) %>%
> >    `+`(geom_point())
> >
> > Further we can write wrapper functions like:
> >
> > p_geom_point <- function(x,...) {
> >    x + geom_point(...)
> > }
> >
> > The run the code like:
> >
> > mtcars %>%
> >    ggplot(aes(x=wt, y=mpg)) %>%
> >    p_geom_point()
> >
> > All three of the above give the same plot from what I can see, but I
> > have not tested it with very many options beyond the above.
> >
> > A really ambitious person could create a new package with wrappers for
> > all the ggplot2 functions that can come after the plus sign, then we
> > could use pipes for everything.  I don't know if there are any strange
> > circumstances that would make this cause problems (it probably will
> > slow things down slightly, but probably not enough for people to
> > notice).
> >
> > On Sun, Dec 6, 2020 at 7:18 PM Avi Gross via R-devel
> > <[hidden email]> wrote:
> >>
> >> 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 might be a pain. Hadley mentioned a slight variant. The first argument to a function now is expected to be the data argument. The second might be the mapping. Now if the function is called with a new first argument that is a ggplot object, it could be possible to test the type and if it is a ggplot object than slide over carefully any additional matched arguments that were not explicitly named. Not sure that is at all easy to do.
> >>
> >> Alternately, 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 will likely not be done. I can live with the plus signs.
> >>
> >>
> >> -----Original Message-----
> >> From: Duncan Murdoch <[hidden email]>
> >> Sent: Sunday, December 6, 2020 2:50 PM
> >> To: Avi Gross <[hidden email]>; 'r-devel' <[hidden email]>
> >> Subject: 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 Gross via R-devel wrote:
> >>> 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 change or enhance the ggplot functionality to have a version that gets rid of the odd use of the addition symbol?
> >>>
> >>> I mean I now sometimes have a pipeline that looks like:
> >>>
> >>> Data %>%
> >>>        Do_this %>%
> >>>        Do_that(whatever) %>%
> >>>        ggplot(...) +
> >>>                geom_whatever(...) +
> >>>                ...
> >>>
> >>> My understanding is this is a bit of a historical anomaly that might someday be modified back.
> >>>
> >>> As I understand it, the call to ggplot() creates a partially filled-in object that holds all kinds of useful info. The additional calls to geom_point() and so on will add/change that hidden object. Nothing much happens till the object is implicitly or explicitly given to print() which switches to the print function for objects of that type and creates a graph based on the contents of the object at that time. So, in theory, you could have a pipelined version of ggplot where the first function accepts something like a  data.frame or tibble as the default first argument and at the end returns the object we have been describing. All additional functions would then accept such an object as the (hidden?) first argument and return the modified object. The final function in the pipe would either have the value captured in a variable for later use or print implicitly generating a graph.
> >>>
> >>> So the above silly example might become:
> >>>
> >>> Data %>%
> >>>        Do_this %>%
> >>>        Do_that(whatever) %>%
> >>>        ggplot(...) %>%
> >>>        geom_whatever(...) %>%
> >>>        ...
> >>>
> >>> Or, am I missing something here?
> >>>
> >>> The language and extensions such as are now in the tidyverse might be more streamlined and easier to read when using consistent notation. If we now build a reasonable version of the pipeline in, might we encourage other uses to gradually migrate back closer to the mainstream?
> >>>
> >>> -----Original Message-----
> >>> From: R-devel <[hidden email]> On Behalf Of Rui
> >>> Barradas
> >>> Sent: Sunday, December 6, 2020 2:51 AM
> >>> To: Gregory Warnes <[hidden email]>; Abby Spurdle
> >>> <[hidden email]>
> >>> Cc: r-devel <[hidden email]>
> >>> Subject: Re: [Rd] New pipe operator
> >>>
> >>> 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 don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
> >>> As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
> >>>
> >>> Hope this helps,
> >>>
> >>> Rui Barradas
> >>>
> >>>
> >>> Às 03:22 de 06/12/20, Gregory Warnes escreveu:
> >>>> 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 Spurdle <[hidden email]> wrote:
> >>>>
> >>>>>> 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)
> >>>>> https://en.wikipedia.org/wiki/Named_pipe
> >>>>> https://en.wikipedia.org/wiki/Anonymous_pipe
> >>>>>
> >>>>> As far as I can tell, the magrittr-like operators are functions (not
> >>>>> pipes), with nonstandard syntax.
> >>>>> This is not consistent with R's original design philosophy, building
> >>>>> on C, Lisp and S, along with lots of *important* math and stats.
> >>>>>
> >>>>> It's possible that some parties are interested in creating a kind of
> >>>>> "data pipeline".
> >>>>> I'm interested in this myself, and I think we could discuss this more.
> >>>>> But I'm not convinced the magrittr-like operators help to achieve
> >>>>> this goal.
> >>>>> Which, in my opinion, would require one to model programs as
> >>>>> directed graphs, along with some degree of asynchronous input.
> >>>>>
> >>>>> Presumably, these operators will be added to R anyway, and (almost)
> >>>>> no one will listen to me.
> >>>>>
> >>>>> So, I would like to make one suggestion:
> >>>>> Is it possible for these operators to *not* be named:
> >>>>>        The R Pipe
> >>>>>        The S Pipe
> >>>>>        Or anything with a similar meaning.
> >>>>>
> >>>>> Maybe tidy pipe, or something else that links it to its proponents?
> >>>>>
> >>>>> ______________________________________________
> >>>>> [hidden email] mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>>
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>>
> >>> Scanned by McAfee and confirmed virus-free.
> >>> Find out more here: https://bit.ly/2zCJMrO
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



--
http://hadley.nz

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel