Deprecate |>

[bramtayl]

No description provided.

[bramtayl]

Not sure if this is fully sufficient. I think might need to be deprecated to a syntax error if we want non-function-like functionality in the future?

[shashi]

This has been discussed before, and the consensus was against removing |>. #20331

[bramtayl]

Recent tide of support here: #5571 (comment)

[StefanKarpinski]

The purpose of deprecating it as a function is to reintroduce it as syntax.

[shashi]

Okay, sounds good.

[yurivish]

Would reintroducing it as syntax mean that you wouldn't be able to alias it, e.g. say | = |> in order to use a different spelling (say at the REPL)?

Slightly OT, but I wonder if there's a more general mechanism that could be used, e.g. operator macros...

[bramtayl]

Not sure if the broadcast test i deleted was important...

[bramtayl]

Worth noting how much uglier code got without chaining (and how much nicer |> x -> expressions could be with syntactic chaining.

[KristofferC]

To me, the code became quite a lot clearer.

[Sacha0]

Echoing Kristoffer, almost every rewrite in this pull request was clearer to me. Best!

[bramtayl]

Does anyone know what these deserializing a remote exception errors mean? I probably made a mistake in the triangular and cholmod files but I don't see a clear line number

[bramtayl]

da da da da da da daaaaaa

[bramtayl]

This looks good to me? CI seems unusually happy

[stevengj]

I have to say, I don't really understand the reason for deprecating this in order to "turn it into syntax". The proposed syntax in #5571 seems to be mostly about currying, not piping. Currying is useful in lots of cases besides piping, so I don't think currying syntax should be tied to a |> operator at all.

[bramtayl]

Right now _ is also deprecated, but if I understand #5571 (comment) correctly, it would given meaning only in combination with |>.

1 |>
   _ + 1 |>
   _ + 1

Would be 3.

I guess it would lower to

|>( |>(1, _ -> _ + 1),  _ -> _ + 1)

[bramtayl]

Here's a particularly horrible line from this PR:

A1 = t1(elty1 == Int ? rand(1:7, n, n) : convert(Matrix{elty1}, (t -> uplo1 == :U ? t : adjoint(t))((t -> chol(t't))(elty1 <: Complex ? complex.(randn(n, n), randn(n, n)) : randn(n, n)))))

Here's how it might be nicer chained:

A1 = 
    randn(n, n) |>
    elty1 <: Complex ? complex.(_, _) : _ |>
    _' * _ |>
    chol |>
    uplo1 == :U ? _ : adjoint(_) |>
    convert(Matrix{elty1}, _) |>
    elty1 == Int ? rand(1:7, n, n) : _ |>
    t1

[bramtayl]

Unless I'm mistaken, this would be might trickier to do with tight currying alone.

[KristofferC]

That chained stuff is completely unreadable to me.

[bramtayl]

I guess as someone who's been doing chaining in R for years the unchained alternative is completely unreadable to me.

[Sacha0]

Both versions are difficult to grok. Better to write such expressions out more clearly if more verbosely. Best!

[stevengj]

Giving _ a meaning only in association with |> seems like a huge mistake to me. A terse partial-application syntax for small functions like f(_,y) or _.a is useful in tons of cases that don't involve chaining.

A terse anonymous-function syntax for more complicated cases, just to save writing x ->..., seems less important.

[bramtayl]

I guess I'd be ok with tight currying too. Vanilla |> and chaining would look like this:

A1 = 
    randn(n, n) |>
    _ -> elty1 <: Complex ? complex.(_, _) : _ |>
    _ -> _' * _ |>
    chol |>
    _ -> uplo1 == :U ? _ : adjoint(_) |>
    convert(Matrix{elty1}, _) |>
    _ -> elty1 == Int ? rand(1:7, n, n) : _ |>
    t1

This is a bit of a mess. The convert line is the only one to take advantage of tight currying. I'm much more of fan of

randn(n, n)
elty1 <: Complex ? complex.(it, it) : it
it' * it
chol(it)
uplo1 == :U ? it : adjoint(it)
convert(Matrix{elty1}, it)
elty1 == Int ? rand(1:7, n, n) : it
t1(it)
A1 = it

ala

#24082

[stevengj]

I agree with @Sacha0 that this example is hideous as a single expression of any kind; it seems better to rewrite it entirely, breaking it into multiple lines or even multiple functions.

[bramtayl]

I'm with you on that. Long chains are definitely confusing and breaking them into shorter chains is usually a good idea.

[stevengj]

@bramtayl, it's not so much the length of the chain in this case as all the conditionals. If these conditionals were split into appropriate functions (and probably handled by dispatch, not by runtime checks), it would be a lot more comprehensible (and also might help type inference):

if elty1 == Int   # probably better to handle this check via dispatch too
   A = rand(1:7, n, n)
else
   A = randn(n,n) |> complexify(elty1, _) |> (X -> X'X) |> chol |> fliptri(uplo1, _) |> Matrix{elty1}
end
t1(A)

[bramtayl]

Yep that looks nice too. No argument from me about splitting out commonly used patterns into functions or that if/else sometimes looks a lot nicer than ?. Even with the simplifications you made, (x -> x'*x) would be nicer as _' * _ unless you wanted to split that out into a function too.

[StefanKarpinski]

When multiple _ are used such as _'_ it is much more common in languages that have these mini closure features to interpret it as (x,y) -> x'y rather than as x -> x'x.

[kmsquire]

If |> is being removed, shouldn't <| also be removed here?

[bramtayl]

Hmm. Not sure. Why?

[bramtayl]

Oh I see. Yeah dunno.

[bramtayl]

I guess I've been convinced by @stevengj that _ is more important for use in tight lambdas than for chaining. I think that |> combined with tight lambdas is nice but really only covers a very small subset of what you can use chaining for. If we want proper chaining in Base we will have to use a different symbol. All that we need for proper chaining is a stand-in for the previous evaluation (something other than _) deprecated for 0.1. I'm curious about @oxinabox's thoughts.

[stevengj]

In cases where a “tight” _ doesn’t work, I’m not convinced that x -> is so onerous.

[bramtayl]

If that's the case, then why _ as a lambda at all?

[oxinabox]

I guess I've been convinced by @stevengj that _ is more important for use in tight lambdas than for chaining.

I 100% agree with that. that having terse lambdas is what the _ proposal is about.
It is an end-in-and-of-itself.
Separately from chaining.
The fact that it would make chaining nicer is a side effect.
Its use in map, reduce, and other higher order functions is what is really attractive.

I'm not a huge fan of chaining these days. (It has its place sure)

I think that |> combined with tight lambdas is nice but really only covers a very small subset of what you can use chaining for.

I'm not sure what in particular you are thinking of.

If we want proper chaining in Base we will have to use a different symbol.

Ergo this deprecation, right?

[stevengj]

I don't support this deprecation, because I think a _ syntax for short (single-call) anonymous functions combined with x-> for longer anonymous functions is sufficient support for chaining in Julia. (Specialized cases that require a fancier DSL can use macros.) |> seems like it should continue to be an ordinary operator.

I don't like the idea of a special currying syntax tied to |>, as I've explained elsewhere, and supporting such a syntax in the future seems to be the whole reason for this deprecation.

[bramtayl]

|> isn't necessary for chaining, so I'd be fine with giving it up to currying.

[StefanKarpinski]

Triage: instead of deprecating, we'll document that |> may become syntax in the future such that using it for pipelining will continue to work as it currently does but overloading it may break.

[oxinabox]

It might be nice to cherry-pick this PR, and keep a lot of the edits to remove |>.
I would say at least half of the code in base cleaner without it.