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

[uniment]

@NiclasMattsson

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.

Thanks for the compliment! I can only wish to be so lucid

@Palli

IF we add such operators, should spaces be mandatory

Spaces are only mandatory in settings where behavior would otherwise be ambiguous; I don’t see how that’s the case here, though I could be missing something.

I’m currently hanging onto hope that good syntax coloring would smooth out the appearance. Maybe a mistake?

@haberdashPI

However the ordering of arguments in [1,2,3]--iseven--filter()--sqrt--map() is pretty confusing as a reader. I think the properties of this operator are just too unintuitive in the current proposal.

The current proposal is no longer proposing --, but instead /> and \>.

What we find though, emerging simply as a surprising result of the operators’ currying properties, is that [1,2,3]\>filter(iseven)\>map(sqrt) is interchangeable with [1,2,3]/>iseven/>filter()/>sqrt/>map().

I’m still mulling over the consequences of this. The obvious benefit is that if a function or functor takes many arguments, but you want to chain into just the second one, there’s a mechanism for it: arg2/>arg1/>func(args[3:end]...).

@haberdashPI

I think this is much clearer: [1,2,3] -- filter(iseven, _) -- map(sqrt, _), and there is already a proposal for tight binding of _ to create anonymous functions (https://github.com/JuliaLang/julia/pull/24990 ); though it remains unclear if that will ever land.

In your example, you’d want to use the standard pipe operator:

[1,2,3] |> filter(iseven, _) |> map(sqrt, _)

But yes, _ curry underscore could make piping into arbitrary argument positions work nicely. In agreement with stevengj, I suspect the only implementation that could gain traction is tight evaluation (one call only). If I’m not mistaken, tight evaluation would mean:

[1,2,3] |> y->filter(x->x≠2, y) |> y->map(x->x^2,y)  ==
[1,2,3] \> filter(x->x≠2) \> map(x->x^2)             ==
[1,2,3] \> filter(_≠2) \> map(_^2)                   ==
[1,2,3] |> filter(_≠2, _) |> map(_^2, _)

thus rendering /> and \> mostly redundant with |> and _.

@adienes

I think it is slightly more consistent with |> if

A /> foo(args) is simply an alias for A |> (x -> foo(A, args)) and
A \> foo(args) is simply an alias for A |> (x -> foo(args, A))

Not sure if I’m totally sold on all the other semantics of --. It seems like it is trying to do too many things.

It’s not trying to do so many things, just those capabilities emerge naturally as a result of its properties.

If we define it as you propose instead, many of those capabilities go away. Is it a good thing? I’m not sure.

@bertschi

Overall, those operators might be more interesting theoretically than practically.

Perhaps.

Afaict, the benefits that /> and \> could bring over |> with _ are:

• to capture the object into a partially applied function, e.g. f = my_obj /> meth, leaving the other arguments unfilled
• to allow one or more arguments and their locations to be chosen before beginning to type the method name, which should be beneficial for autocomplete to match the method signature in realtime.

I know some folks downplay the importance of autocomplete, but it does reduce mental loading quite a bit.

Oh yeah, forgot the most important benefit of />:

• most natural feel for OOP programmers, e.g. my_obj /> meth(args...)

Okay okay that was a joke, don’t hurt me. I know we don’t care about the OOP folks.

But yeah, tight _ currying does attenuate the impetus for /> and \>. I’m curious to see where the cards land.