Another option is https://github.com/hadley/ggplot1 🤣 Hadley
On Wed, Dec 9, 2020 at 1:24 PM Duncan Murdoch <murdoch.dun...@gmail.com> 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 > > <r-devel@r-project.org> 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 <murdoch.dun...@gmail.com> > >> Sent: Sunday, December 6, 2020 2:50 PM > >> To: Avi Gross <avigr...@verizon.net>; 'r-devel' <r-devel@r-project.org> > >> 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 <r-devel-boun...@r-project.org> On Behalf Of Rui > >>> Barradas > >>> Sent: Sunday, December 6, 2020 2:51 AM > >>> To: Gregory Warnes <g...@warnes.net>; Abby Spurdle > >>> <spurdl...@gmail.com> > >>> Cc: r-devel <r-devel@r-project.org> > >>> 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 <spurdl...@gmail.com> 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? > >>>>> > >>>>> ______________________________________________ > >>>>> R-devel@r-project.org mailing list > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>>> > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org 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 > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > ______________________________________________ > 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
