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?

|^>
^>

[rben01]

@tk3369

Without the help of Unicode, i would want to see a directional change of data movement. Just some ideas below... thoughts?

I agree that it's important to pick a syntax that is visually suggestive of the split path. My vote would be for x %> f. The percent sign suggests data has been split, with the lower half getting trapped in the > (so it doesn't continue on) while the upper half uses a ramp (the slash in %) to hop over f and land on the other side.

[LilithHafner]

If someone wants to put this in a package and add a new infix operator at the appropriate precedence level that seems very likely to go through as a minor change. (personal opinion, not from triage)