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
