Create backpipe %<% operator

[ctbrown]

There are times when it is desirable to reverse the direction of the pipe operator to match the order of parenthesis. The motivating example is a shiny application in which the shiny commands build up HTML. A backpipe operator would preserve the hierarchy of the HTML while cleaning up the code immensely. Consider:

require(shiny)
# Original Shiny: 
div( class="color-green",  h1( "Header 1" ) )

# Current magrittr:
h1( "Header 1" ) %>% div( class="color-green" )    

# proposed 
div( class="color-green" )  %<% h1( "Header 1" ) 

The proposed syntax not only make the code more readable, but alos preserves the hierarchical nature of the HTML so the code more closely matches the generated HTML.

( BTW, I am already doing this with shiny application by simply cloning %>% and reversing the order of the arguments. I have not investigated how this would work with the changes for 1.1.0. I am happy to submit code if @smbache thinks this is a useful feature. )

[smbache]

This is an interesting example; and I do agree that there are examples where it can be useful. It is not obvious how to incorporate this in the current setup, as the LHS'es are evaluated as the the chain proceeds and altering the call ex-post is not possible (or at least not entirely worth the trouble). But I'll keep it in mind as I am considering new approaches, and whether the entire chain should be considered before any evaluation takes place... Maybe then it can be done in a more natural way.

[smbache]

Also, it is not really clear what shoul happen if you mix the two

value %>% fun1(arg1) %<% fun2(arg2)

[ctbrown]

I can't think of a use case in which you would ever think of mixing the two. You can't cross the streams. That would be chaos: Human sacrifice, dogs and cats living together... mass hysteria!

[piccolbo]

I think fun1 should take the left side pipe as first argument, and the
right side as second argument, such as
left.table %>% merge(by = "id") %<% right.table. For functions with more
arguments, we could have additional operators such as in

f(arg1, arg2, arg3, arg4)
#translates to

     arg1
     %V%

arg2 %>% f %<% arg3
%^%
arg4

This way we could express complex expressions as DAGs in a graphical form.
Extending these forms to the third and higher dimensions may run into
parser limitations, but is an exciting research direction.
Additionally, I think the evaluation of a backpipe expression should
generate sound of this sort https://www.youtube.com/watch?v=pD45tbBluBc

Antonio

On Fri, Aug 1, 2014 at 9:07 AM, Christopher Brown notifications@github.com
wrote:

I can't think of a use case in which you would ever think of mixing the
two. You can't cross the streams. That would be chaos: Human sacrifice,
dogs and cats living together... mass hysteria!

—
Reply to this email directly or view it on GitHub
#26 (comment).

[smbache]

Hah! maybe you can add a few diagonal outlets to that graph for assignment! :-p

[gaborcsardi]

It would be actually cool to be able to have a way to define a DAG for data processing. You could define what the inputs are, and how exactly they flow trough the DAG, the functions at the nodes, which piece will be which argument of the function, etc. Conditional nodes would push the data along different branches, and the data that arrives at the special output node would be the output.

We could design some syntax for describing such a DAG! We could call it, ehm, R, maybe? Oh wait

[piccolbo]

@gaborcsardi we could design some better syntax for the same DAGs, or should we leave all the fun to @smbache?
@smbache You've got it

       arg1 arg2 arg3
         %\%%V%%/%
   arg4 %>%  f  %<% arg5
         %/%%^%%\%
       arg6 arg7 arg8

It's becoming more like compiling ASCII art. Or a cellular automaton.

[smbache]

Maybe I'll leave this to someone who could write a daggr package; stab right through the heart of simplicity! ;-)

[gaborcsardi]

:)

Actually, why stop with DAGs? Let the data flow through loops of pipes, in the circle of life!

What is the output then, you might ask. Well, it can be stable attractors, oscillations, other quasi-spatio-temporal patterns. But who cares what the output is, anyway? Who would want to quit such a program?

[ctbrown]

Despite, you guys getting your yucks about this ... ( looking at you @piccolbo ;) ) There does seem to be some interest in this:

http://stackoverflow.com/questions/31305342/is-right-to-left-operator-associativity-in-r-possible

[piccolbo]

It seems to me that the main point of %>% is how it rearranges tokens so that related things are closer together. I look at @ctbrown example and the one on SO and I don't see any rearrangement.

# Original Shiny: 
div( class="color-green",  h1( "Header 1" ) )

# proposed 
div( class="color-green" )  %<% h1( "Header 1" ) 

Order is identical, trading a comma for a %<%, one lowly parens moving a tiny bit. Am I trivializing things, missing the point? Maybe an example with two consecutive uses of the operator levels would help me.

Sorry for veering on the comedic side on the DAGs but I was serious about them. I will open another issue if anybody's interested.

[piccolbo]

Well, the SO example has three or more consecutive uses of %<% or equivalent.

[ctbrown]

@piccolbo

No worries about the comedic side.

Exactly! The utility of back-piping becomes more apparent with increased complexity. Compare:

# Original Shiny:
     h1( div( class="color-green", div( class="text-bold", div( class="date", "2015-08-26" ) ) ) )

# Proposed
    h1 %<% 
       div( class="color-green" ) %<% 
       div( class="text-bold" ) %<% 
       div( class="date", "2015-08-26 ) 

The latter is more legible than the former.

While it might be argued that magrittr as is, would be equally as legibly, the back-piping allows the operations to appear in the same order appears as the generated HTML. This makes debugging infinitely easier.

What I might concede is that a backpipe operator does not belong in the magrittr package, but should be a different package, e.g. magrittr.backpipe or something so as not to overbloat magrittr.

Really my only point in posting is to be complete in the documentation of this issue and capture the additional data point of the SO post.

[piccolbo]

I always write my code that way and I don't have any backpipes! I write my code so that indentation is proportional to depth in the parse tree for the n top levels, and on one line below n, n varies a little bit heuristically, I must admit. I am also thinking about a formatter that automates this approach.

    h1(
       div( class="color-green" ),
       div( class="text-bold" ),
       div( class="date", "2015-08-26" ))

You don't need backpipes to write your code nicely, you just need to underwrite the principles of semantic formatting. Wait a second, I haven't written them down yet ...

[ctbrown]

Except what you didn't write the same code. You meant:

h1(
   div( class="color-green" ,
     div( class="text-bold",
       div( class="date", "2015-08-26" )
     )
  )

IMO, this is not as clear as my example, indentation or not..

[piccolbo]

I stand corrected.

On Fri, Aug 28, 2015 at 12:22 AM Christopher Brown notifications@github.com
wrote:

Except what you didn't write the same code. You meant:

h1(
div( class="color-green" ,
div( class="text-bold",
div( class="date", "2015-08-26" )
)
)

IMO, this is not as clear as my example, indentation or not..

—
Reply to this email directly or view it on GitHub
#26 (comment).

[rodrigomurta]

A reverse magrittr would be nice. Here is a StackOverflow related question.
Is right-to-left operator associativity in R possible?
and this other related to operator visualisation in RStudio:
is-it-possible-to-beautifully-display-the-pipeline-character-in-rstudio

[ctbrown]

@rodrigomurta

• The first of your SO links, is-right-to-left-operator-associativity-in-r-possible was previously documented above.
• The second returned a "page not found", try is-it-possible-to-beautifully-display-the-pipeline-character-in-rstudio.

[ctbrown]

Also:

I just submitted a package to CRAN called backpipe that provides a "reverse pipe" (right-to-left) operator for both magrittr and pipeR (and any other forward left-to-right operator for that matter). It can also be found here on github.

[rodrigomurta]

@ctbrown
Wrong link syntax. Corrected. Tks!

[ctbrown]

The backpipe package has been accepted by CRAN, AFAIAC you can close this issue.

[smbache]

great!