Only when the transformed argument is the first argument of every method in your call notation/the last argument of every method in parenthesized Polish notation. That’s often not the case, hence the need for Pipe.jl, Chain.jl, etc. where you can specify the location of the argument in each transformation call.
Associating to the right its actually the last argument, i.e., it works nicely with map and filter, but no longer with the intended use – at least originally – with the object being the first argument. Too bad, guess we have to live with @chain and friends for now 
.
With the proposed operator properties, how will this expression be evaluated?
my_object -- meth1(args1…) -- meth2(args2…)
It probably wouldn’t work except when meth1(args1...) is again a function taking my_object as an argument and get applied immediately, i.e.,
my_object -- partial(meth1, args1...) () -- partial(meth2, args2...) ()
We certainly have been carried away a bit from the original idea, but it was fun to think it through, i.e., as an alternative syntax for partial function application in chaining pipelines. Guess for most use cases, @chain and friends are quite nice already.
Would my_object -- meth1(args1…) -- meth2(args2…) not be interpreted as meth2(meth1(my_object, args1…), args2…)?
Guess this was the original idea, it changed though with the example above and when you claimed:
Given that, my_object -- meth1(arg1, arg2) would no longer work, but would need to be written as
my_object -- arg2 -- arg1 -- meth1 ().
With the behavior we have discussed described by
--(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
the expression my_object -- meth1(arg1, arg2) would evaluate to meth1(my_object, arg1, arg2) exactly as desired.
No, it would not work if -- is defined as a function:
julia> minusminus(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...) # --(obj, meth)
minusminus (generic function with 1 method)
julia> meth1(obj, arg1, arg2) = (obj, arg1, arg2) # just an example method
meth1 (generic function with 1 method)
julia> minusminus(:my_object, meth1(:arg1, :arg2)) # :my_object -- meth1(:arg1, :arg2)
ERROR: MethodError: no method matching meth1(::Symbol, ::Symbol)
Closest candidates are:
meth1(::Any, ::Any, ::Any) at REPL[13]:1
The problem is that meth1(:arg1, :arg2) needs to be interpreted as partial application here, i.e., the former would work if you define a suitable partial1 application and then apply the resulting function:
julia> partial1(meth, args...) = obj -> meth(obj, args...)
partial1 (generic function with 1 method)
julia> minusminus(:my_object, partial1(meth1, :arg1, :arg2))()
(:my_object, :arg1, :arg2)
In order to splice the first argument into the call, you need a macro, i.e., a special syntax. This case is exactly handled by @chain:
julia> using Chain
julia> @chain :my_object meth1(:arg1, :arg2)
(:my_object, :arg1, :arg2)
julia> @macroexpand @chain :my_object meth1(:arg1, :arg2)
quote
local var"##314" = :my_object
local var"##315" = meth1(var"##314", :arg1, :arg2)
var"##315"
end
Remember that we have decided -- should bind more tightly than the function call, so that my_object--meth1(arg1, arg2) will evaluate as (my_object--meth1)(arg1, arg2)
You are right, had missed that. Then, it would certainly work
julia> minusminus(:my_object, meth1)(:arg1, :arg2)
(:my_object, :arg1, :arg2)
Cool, would be a very nice infix operator indeed. Unfortunately, right associativity and precedence requires a (breaking ?) change to the parser. Would try it out in Haskell, if I knew how to type it 
1 Like
I love the progress we’re making. 
To summarize, the current proposal is an infix operator -- (“dash”) defined as
--(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
which has tighter binding than function calls, and has right-associativity.
We have found that this operator will satisfy the desire to chain operations on an object threaded as a first argument through a sequence of methods,
my_object--meth1(args1...)--meth2(args2...)--meth3(args3...) ==
meth3(meth2(meth1(my_object, args1...), args2...), args3...)
And, as a happy surprise, it also works well for chaining functions whose first argument is a function
[1,2,3]--iseven--filter()--sqrt--map() ==
map(sqrt, filter(iseven, [1,2,3]))
This is a much better operator than expected.
Oh, and as a weird bonus, you can also evaluate expressions in Reverse Polish Notation:
3 -- 4 -- -() -- 5 -- +() == 5 + (4 - 3)
The things to work out, it seems, are:
- confirm that we understand it correctly
- check how difficult it would be to implement in the language
- check that broadcasting would work, e.g.
[1, 2, 3]--iseven.() == iseven.([1, 2, 3])
Thoughts? 
Do we need a special broadcasting syntax? In any case, it would just need to lower as
[1,2,3] -- iseven -- broadcast ()
by the discussion on map above.
1 Like
Julia already has right-associative operators (e.g. =, <|, <--, ←, ⇇, etc.), so I assume adding another won’t be an issue.
Elevating an operator to bind more tightly than function call, however, I don’t know.
Insisting we all use macros and non-standardizable syntax which can never be part of the core language, just to pipe into arbitrary argument positions, seems sadomasochistic. For what? So that we can pretend functional multidispatch languages somehow magically make one argument position not matter more than any other? when the do statement already shows we don’t actually believe that, as do Clojure’s threading macros?
The ability to insert into arbitrary positions is usually more hassle than not, requiring more characters and introducing more mental load, because for functions that have been defined well the object to be chained is usually the first or second argument anyway. Which the proposed operator -- handles nicely:
"Hello, world!"--split(",")--uppercase--map()--join(":") ==
join(map(uppercase, split("Hello, world!", ",")), ":") ==
"HELLO: WORLD!"
x--skipmissing()--isodd--filter() ==
filter(isodd, skipmissing(x))
To understand how this works, consider this:
f(a, b, c, d) ==
a--f(b, c, d) ==
b--a--f(c, d) ==
c--b--a--f(d) ==
d--c--b--a--f()
Yeah you probably won’t actually want to pull all the arguments out of the parentheses in reverse order, but as we’ve seen usually all you care for is the first one or two.
1 Like
Nice example of how an argument can be inserted at any position. Just to try out the new syntax, I have hacked together a small macro which rewrites ++ (a valid and as of now unused operator) into right-associative calls of minusminus (our higher-order function corresponding to the invalid operator --):
using MacroTools: postwalk, @capture
minusminus(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
function unchain(terms::AbstractVector, stack::AbstractVector)
if isempty(terms)
:(foldr(minusminus, [$(stack...)]))
elseif @capture(terms[1], f_(args__)) && f != :foldr # don't touch nested transforms again
arg = :(foldr(minusminus, [$(stack...), $f])($(args...)))
unchain(terms[2:end], push!([], arg))
else
unchain(terms[2:end], push!(stack, terms[1]))
end
end
macro calumet(expr)
postwalk(expr) do ex
if @capture(ex, ++(args__))
unchain(args, [])
else
ex
end
end
end
Both of your examples now work as follows:
julia> @calumet "Hello, world!"++split(",")++uppercase++map()++join(":")
"HELLO: WORLD!"
julia> @calumet let x = [1,2,missing,4,5,missing]; x++skipmissing()++isodd++filter() end
2-element Vector{Int64}:
1
5
Also nested transformations should work, but I have not tested extensively:
julia> @calumet 1 ++ 2 ++ Base.:+() ++ (3 ++ 4 ++ Base.:+()) ++ Base.:*()
21
2 Likes
Are /> and \> available where one could curry into the first argument and the other the last, otherwise using the same semantics as -- ? or would this be too confusing
Holy wow that was fast! You’re a wizard! Admittedly I began looking into writing a macro to do this, but you beat me to the punch by a wide country mile 
This is really cool! Although, two complaints:
- I’ve begun to use the
++operator for the parallel sum, as seen here. - This macro doesn’t yet work for broadcasting a function across a collection, e.g.
[1,2,3]++sqrt.().
I know I know, eventually we’d settle on dash --, I’m pulling your leg.
This is really great. I like the “peace pipe” reference too. 
Masterful. I’m going to play with this for a while, and maybe some other folks can play with it too and see what else it’s good for (and what it’s not).
Similar to dash --, /> and \> are not valid operators, which means we would need them to be added into the language first; it also means we could claim them without breaking backwards compatibility in any packages or programs, if we can convince the Julia devs to incorporate them.
There was a brief moment when I was considering emdash --- for piping the object into the last argument position, such as arr---map(sqrt). If it has otherwise the same properties as we have chosen for dash -- (higher precedence than function call, and right-associativity), then the following is true:
f(a, b, c, d) ==
d---f(a, b, c) ==
c---d---f(a, b) ==
b---c---d---f(a) ==
a---b---c---d---f()
This operator would be nice for map, reduce, filter, etc., and especially well-suited for mapreduce, e.g.:
[1, 2, 3]---filter(iseven)---map(sqrt) == # using emdash
[1, 2, 3]--iseven--filter()--sqrt--map() # using dash
[1, 2, 3]---mapreduce(x->x^2, +) == # using emdash
[1, 2, 3]--(+)--(x->x^2)--mapreduce() # using dash
And if dash -- and emdash --- have the same precedence, then they should chain as expected, e.g.:
[1, 2, 3]---mapreduce(x->x^2, +)--sqrt() ==
[1, 2, 3]--(x->x^2)--map()--(+)--reduce()--sqrt() ==
sqrt(mapreduce(x->x^2, +, [1, 2, 3]))
However, I’ve begun thinking that dash -- is sufficiently expressive to cover the vast majority of use cases, that the ease of typing it beats the other options we’ve considered (except perhaps ..), and that adding more and other operators to serve these purposes would bring more confusion and mental loading than it’s worth.
But I’m open to the idea that I’m wrong. Maybe you can convince me?
1 Like
Playing around a bit, this could get really confusing 
As specified previously, let dash -- and emdash --- be defined as:
--(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
---(obj, meth) = (args...; kwargs...) -> meth(args..., obj; kwargs...)
meaning that -- partials an object into the first argument position and --- partials an object into the last argument position. Make them bind more tightly than function call, be right-associative, and have equal precedence such that:
f(a, b, c, d) ==
a--f(b, c, d) ==
b--a--f(c, d) ==
c--b--a--f(d) ==
d--c--b--a--f() ==
d---f(a, b, c) ==
c---d---f(a, b) ==
b---c---d---f(a) ==
a---b---c---d---f()
It gets really weird if you start intermixing them; you end up with a lot of different ways to call a function:
f(a, b, c, d) ==
d---b--a--f(c) ==
c---d---b--a--f() ==
d---a--f(b, c) ==
b--d---a--f(c) ==
c---b--d---a--f() ==
a--c---d---f(b) ==
b--a--c---d---f() ==
a--d---f(b, c) ==
c---a--d---f(b) ==
b--c---a--d---f()
And although they are numerous, they are not arbitrary; arguments can only be picked off the argument list from the left end or the right end, one at a time. (Note: for a single-argument function, arg--f() and arg---f() are equivalent.)
This seems so insidious that I’m leaning toward disallowing it, and banishing the emdash --- operator altogether in favor of having only the dash -- operator. As mentioned previously, most well-designed functions have whatever object you might wish to chain in the first or second argument position anyway; even if it might be somewhat uglier to use -- for calling map or filter, the Pandora’s box that --- opens up isn’t worth the convenience imo.
Heck, I’d rather use the half dozen piping packages than live in a world where -- and --- coexist.
Please try to convince me otherwise! 
1 Like
I’m coming around to the idea of having both operators, and I’m starting to like @adienes’ idea to use /> and \>. Apologies for changing my mind so quickly.
New Proposal (Compare with old proposal)
Two infix operators, /> (“fill” or “frontfill”) and \> (“backfill”), defined as
/>(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
\>(obj, meth) = (args...; kwargs...) -> meth(args..., obj; kwargs...)
which bind more tightly than function calls, have right-associativity, and have equal precedence to each other.
These operators generate partially applied functions, calling the method to the right on the object to the left—frontfill /> filling the object as a first argument and backfill \> filling the object as a last (non-keyword) argument—operating as follows:
my_obj/>meth1(args1...)/>meth2(args2...)/>meth3(args3...) ==
meth3(meth2(meth1(my_obj, args1...), args2...), args3...)
my_obj\>meth1(args1...)\>meth2(args2...)\>meth3(args3...) ==
meth3(args3..., meth2(args2..., meth1(args1..., my_obj)))
and can be used in conjunction with each other for chaining operations:
"Hello, world!"/>replace("o"=>"e")/>split(",")/>uppercase.()/>join(":") ==
join(uppercase.(split(replace("Hello, world!", "o"=>"e"), ",")), ":") ==
"HELLE: WERLD!"
"1, 2, 3, 4"\>eachmatch(r"(\d+)")\>map(x->x[1]\>parse(Int))\>filter(iseven)/>sum() ==
sum(filter(iseven, map(x->parse(Int, x[1]), eachmatch(r"(\d+)", "1, 2, 3, 4")))) ==
10
Why am I changing my mind? Because as coders we already have plenty of ways to make code illegible, yet we don’t because it doesn’t help us. We might as well offer both tools—frontfill and backfill—and trust that we won’t abuse them.
Although /> and \> are slightly more awkward to type than --, it’s not too bad. Especially if you type them a lot because it’s actually a useful feature, you get good at it (also anybody who’s typed a lot of XML should already be good at typing />). In addition, they also exhibit stylistic cohesion with the existing pipe operator |>. (may or may not be a good thing.)
I’m really excited to watch autocomplete work with this and pop up dialogs with matching method signatures.
3 Likes
I confess to having been somewhat exasperated by this thread. First it was apparent shoehorning of unmotivated OOP syntax into Julia, then it seemed as if Julia-is-not-at-that-stage was being willfully ignored, and finally the -- and --- operators were proposed. Maybe it’s just me, but I find those operators almost comically terrible, as if developers of the Brainfuck language had snuck into our forum and were drunk-posting just to troll us. And at first I felt the same way about /> and \>.
But on further reflection they’re actually starting to look pretty interesting and useful. As you say, /> and \> work together with |> as an extended family of piping operators. Yes, they can be abused to make illegible code but so can everything. And I don’t think newbies will find them more confusing than existing argument transformation syntax like f() do … end blocks.
So I’m tentatively going to click like on your proposal because I hope people like me who’ve been averse to this thread will notice and comment on it - especially those with insight into Julia’s parser who can clarify whether this is at all feasible. And kudos to everyone involved for persisting!
(But consider editing your post again to add spaces around the pipes. Legibility is everything, and you need this to be attractive to sell it.)
5 Likes