# Allowing the object.method(args...) syntax as an alias for method(object, args ...)

**URL:** <https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051>\
**Category:** Internals & Design\
**Tags:** question, design\
**Created:** [May 29, 2021, 5:09pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051 "2021-05-29T17:09:54Z")\
**Posts on this page:** 20\
**Page:** 10

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [October 9, 2022, 4:24pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/188 "2022-10-09T16:24:07Z")

</div>

> [@bertschi](#):
>
> but the one proposed here seems quite nice for processing pipelines were a single argument is successively transformed on each `()`

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.

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 4:34pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/189 "2022-10-09T16:34:26Z")

</div>

> [@Benny](#):
>
> > [@bertschi](#):
> >
> > but the one proposed here seems quite nice for processing pipelines were a single argument is successively transformed on each `()`
> 
> 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 😉.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 9, 2022, 4:48pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/190 "2022-10-09T16:48:47Z")

</div>

With the proposed operator properties, how will this expression be evaluated?

```julia
my_object -- meth1(args1…) -- meth2(args2…)

```

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 5:10pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/191 "2022-10-09T17:10:39Z")

</div>

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.,

```julia
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.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 9, 2022, 5:14pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/192 "2022-10-09T17:14:08Z")

</div>

Would `my_object -- meth1(args1…) -- meth2(args2…)` not be interpreted as `meth2(meth1(my_object, args1…), args2…)`?

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 5:19pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/193 "2022-10-09T17:19:42Z")

</div>

> [@uniment](#):
>
> 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:

> [@uniment](#):
>
> This is a misunderstanding. `arr--fun` is a function, and `arr--fun()` applies the function to produce a value.

Given that, `my_object -- meth1(arg1, arg2)` would no longer work, but would need to be written as  
`my_object -- arg2 -- arg1 -- meth1 ()`.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 9, 2022, 5:29pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/194 "2022-10-09T17:29:51Z")

</div>

> [@bertschi](#):
>
> 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

```julia
--(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.

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 5:51pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/195 "2022-10-09T17:51:58Z")

</div>

No, it would not work if `--` is defined as a function:

```julia
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
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
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

```

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 9, 2022, 6:10pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/196 "2022-10-09T18:10:38Z")

</div>

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)`

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 6:23pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/197 "2022-10-09T18:23:56Z")

</div>

You are right, had missed that. Then, it would certainly work

```julia
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 😀

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 9, 2022, 7:03pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/198 "2022-10-09T19:03:41Z")

</div>

I love the progress we’re making. 😃

To summarize, the current proposal is an infix operator `--` (“dash”) defined as

```julia
--(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,

```julia
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

```julia
[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:

```julia
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? 💭

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 9, 2022, 7:13pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/199 "2022-10-09T19:13:50Z")

</div>

Do we need a special broadcasting syntax? In any case, it would just need to lower as

```julia
[1,2,3] -- iseven -- broadcast ()

```

by the discussion on `map` above.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 10, 2022, 10:15pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/200 "2022-10-10T22:15:44Z")

</div>

> [@bertschi](#):
>
> Unfortunately, right associativity and precedence requires a (breaking ?) change to the parser.

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.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 11, 2022, 7:06pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/201 "2022-10-11T19:06:11Z")

</div>

> [@Benny](#):
>
> > [@bertschi](#):
> >
> > but the one proposed here seems quite nice for processing pipelines were a single argument is successively transformed on each `()`
> 
> 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.

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](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/198) `--` handles nicely:

```julia
"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:

```julia
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.

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [October 11, 2022, 9:02pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/202 "2022-10-11T21:02:26Z")

</div>

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 `--`):

```julia
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
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
julia> @calumet 1 ++ 2 ++ Base.:+() ++ (3 ++ 4 ++ Base.:+()) ++ Base.:*()
21

```

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [October 11, 2022, 9:23pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/203 "2022-10-11T21:23:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 12, 2022, 12:41am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/204 "2022-10-12T00:41:09Z")

</div>

> [@bertschi](#):
>
> 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 `--`):

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](https://stackoverflow.com/a/74010780/20201943).
- 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](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/198) `--`, 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).

> [@adienes](#):
>
> 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

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](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/168) 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`:

```julia
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.:

```julia
[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.:

```julia
[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?

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 12, 2022, 4:31am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/205 "2022-10-12T04:31:00Z")

</div>

Playing around a bit, this could get really confusing 😂

As specified previously, let dash `--` and emdash `---` be defined as:

```julia
--(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:

```julia
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:

```julia
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! 🗣

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 12, 2022, 8:27am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/206 "2022-10-12T08:27:44Z")

</div>

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](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/198))

Two infix operators, `/>` (“fill” or “frontfill”) and `\>` (“backfill”), defined as

```julia
/>(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:

```julia
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:

```julia
"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.

---

<div class="post-metadata">

**Author:** ![NiclasMattsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/niclasmattsson/32/21988_2.png) [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)\
**Post date:** [October 12, 2022, 10:21am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/207 "2022-10-12T10:21:14Z")

</div>

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](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872) 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](https://en.wikipedia.org/wiki/Brainfuck#Hello_World!) 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.)

[Previous page](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051.md?page=9)

[Next page](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051.md?page=11)