Improvement for function chaining operator

Internals & Design
1

Dear Julia founders and maintainers, please consider changing the function chaining (piping) operator to accept call specifications. The new syntax, as I see it would look like:

var >. callable(opt_param1, opt_param2)

and would mean precisely "take whatever on the left side of the operator and pass it as the first parameter to the callable on the right side, along with other optional parameters provided in the call.

Yes, this will essentially introduce “abominable” object-oriented syntax in Julia. Please don’t start lecturing me about the merits of multiple dispatch - I know and agree. The thing is I love Julia. I love Julia that much that I hope one day it will overtake Python, Java, and other high-level programming languages, but to achieve this Julia has to become more user and beginner-friendly. The syntax like var.func1(param1, param2).func2(param3, param4) is extremely ubiquitous in programming and I believe one of the key things that made object-oriented programming so popular.

I propose syntax >. for this new piping operator because it is much easier to type than |> and it is currently available. Not only it will make Julia immediately more appealing to millions of object-oriented developers and beginners (without losing a bit of its current features) this will also make possible implementing proper autocompletion in Julia editors. Developers use autocompletion because it helps navigate things that you can potentially do next, not because it corrects spelling. If this operator was made part of language syntax, editors would be able to list all functions that potentially accept “type on the left” as the first argument whenever somebody types >.

I am not asking for a macro hack that will make some resemblance of such operator possible in the current syntax. I am asking to consider adding this operator in some future versions of Julia language.

And thank you very much for your incredible work! You are my heroes!

2

The reason this won’t happen is it would seriously conflict with the . Syntax for vectorization.

1 Like
3

Someday when we agree of how #24990 should work and we can write the fairly neat
var |> callable(_, opt_param1, opt_param2)

Edit: I don’t see why |> instead of >. makes much difference. Also, why not a “macro hack”?

4

Sorry, I don’t see how.
The vectorisation syntax:

callable.(var, param1, param2)

The proposed syntax with vectorisation:

var >. callable.(param1, param2)

Really the >. syntax does not seem to appear anywhere now.
If passing left argument as first parameter inflicts aversion, it is possible to optionally use placeholder parameter (underscore) to indicate place where the left argument should go:

var >. callable(_, param1, param2)

However the first syntax is more readable both are actually acceptable.

5

How would it interact with functions like + that are infix?

6

This looks promising! Thank you!

>. is 10 times easier to type than |> Just try it. And consider, when implemented, this operator will be used quite often.

As for ‘not macro’, for once I’m not asking for a solution for myself, I hope to make the language more appealing to beginners so it will become more popular. It has to be generally accepted syntax and not just some hack for the knowing.

For the same reason I’d vote for inclusion of SimpleTraits.jl into the core library and making it standard for implementing interfaces. Having something officially supported and having it as some module with the hack that you can find online is not the same.

7

Well, obviously a + b equals to a >. +(b), or a >. +(_, b) with placeholder syntax. However I don’t see why anyone would use this syntax, to begin with.