Reserve some syntax for a tee pipe

[davidanthoff]

R's magrittr has the tee pipe %T>%. The difference with the normal pipe %>% is that an expression like a %T>% b returns a, not b. This can be super useful in data processing pipelines a la dplyr (and what I'm currently building out with the standalone operators in Query.jl).

It would be great if julia could at some point get something like that as well. One option would be |>>. It would kind of signal that the stuff on the left hand side is going to be moved one more over in a pipe, i.e. something like a |>> b |> c to me looks fairly reasonable in that it signals that the return value of a would "jump" over b. But I'm sure there are other ideas as well, so I'm not super wedded to this specific syntax.

It is not clear to me whether something like |>> could be introduced in julia 1.x, or whether that would be breaking. When I do a |>>b I get an error ERROR: syntax: ">" is not a unary operator. I think that means one could define |>> in a julia 1.x without breaking anything, but is that right?

If that is correct, great. But if not, i.e. if this would be breaking, is there a chance that we could make some syntax illegal for julia 1.0, with the plan to later enable this kind of tee pipe in some 1.x version?

[davidanthoff]

@StefanKarpinski mentioned somewhere that we should bump issues that we would like the core team to look at before the alpha. Here we go, BUMP.

Most likely that answer here is just that this could be done in 1.x if there is agreement, and we can move on for now. But I'm not sure, so would be great if someone with a better understanding could look at this.

[StefanKarpinski]

There are a few cases to check and they're all errors currently:

julia> |>>
ERROR: syntax: "|>" is not a unary operator

julia> 1 |>>
ERROR: MethodError: no method matching >(::Int64)
Closest candidates are:
  >(::Any, ::Any) at operators.jl:283
  >(::BigFloat, ::BigFloat) at mpfr.jl:698
Stacktrace:
 [1] |>(::Int64, ::typeof(>)) at ./operators.jl:774
 [2] top-level scope

julia> |>> 2
ERROR: syntax: "|>" is not a unary operator

julia> 1 |>> 2
ERROR: syntax: ">" is not a unary operator

So the only dangerous case is "postfix |>>" which parses as |>(1, >) which calls >(1). As long as we don't introduce a meaning for that we're fine. In any case, I think this is such a syntax corner case that even if adding this operator later is slightly technically breaking, it would be fine to do in 1.x.

[davidanthoff]

Cool, thanks!

[davidanthoff]

I'm wondering whether we could revisit this? I don't know how to add something like this to the parser, but the PR that @tfk just opened at #34340 makes me think that this can't be difficult for someone who knows what they are doing :) Any help would be appreciated!

The function itself would be extremely simple:

function |>>(x, f)
  f(x)
  return x
end

I think would do it, right?

[tkf]

If you look at the diff 56d2556 it's super simple. I think you just need something like

(define prec-pipe>       (add-dots '(|\|>| |\\>| /> |\|>>|)))

(or maybe |\|>>| has to be at the beginning of the list?)

[tkf]

@​tfk just opened at #34340

@davidanthoff BTW you might want to use @tkf to avoid pinging another person :)

[c42f]

Over at #34340 (comment) the operator |!> was mentioned for this. I like it!

[tk3369]

Sounds nice! My only concern is that it is difficult to learn to read this new operator unless we have a more visually meaningful look. Without the help of Unicode, i would want to see a directional change of data movement. Just some ideas below... thoughts?

|^>
^>