IF we add such operators, should spaces be mandatory (I use them and feel better with piping in Unix, but it would be too late, or breaking to require for older |>)? There’s one precedent for space required for operators, a ? b : c, and while space/indentation is not meaningful in general in Julia, if I recall there’s one more such corner case. [Plus style-guides recommend spaces in some cases, and against in others.]
Maybe
julia> 2 .+(1:3);
julia> 2.+(1:3);
ERROR: syntax: invalid syntax "2.^"; add space(s) to clarify
?
2 Likes
I share similar feelings to @NiclasMattsson
I think this is starting to turn into a more and more interesting idea for a higher-order operator over functions. So, first of all, thanks for your civil discourse and thoughtfulness.
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.
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.
5 Likes
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.
1 Like
Well in a sense, A /> foo(args...) acts like A |> x -> foo(x, args...), but is also a higher-order function in its own right, i.e.,
A /> foo(args) == (A /> foo)(args) # by precedence
== ((xs...) -> foo(A, xs...))(args...) # by definition of />
== foo(A, args...) # by beta reduction
Together, the two operators /> and \> are quite powerful and basically allow to pass arguments one-by-one to a function, either from the front or back respectively. Thus
f(a, b, c, d, e) = (a, b, c, d, e)
⬚ -> f(1, 2, ⬚, 4, 5) == 2 /> 1 /> 4 \> 5 \> f
and in a chain we can use a suitable sequence of /> and \>to insert the starting argument at any desired position (together with regular function application either one of the operators is sufficient already; when functions cannot be called regularly, both would be needed). Taking this further, tacit or point-free programming would also be possible, i.e., use the operators to fill all but one argument and then compose the resulting functions.
When the syntax hinted at by @haberdashPI is available there is no need for these operators, as we can simply use the regular |>, i.e.,
[1,2,3] |> filter(iseven, _) |> map(sqrt, _) == [1,2,3] |> ⬚ -> filter(iseven, ⬚) |> ⬚ -> map(sqrt, ⬚)
== [1,2,3] \> filter(iseven) \> map(sqrt)
== [1,2,3] /> iseven /> filter() /> sqrt /> map()
Overall, those operators might be more interesting theoretically than practically. As a first step, one could maybe implement a VSCode plugin that hides ⬚-> such that ⬚ -> f(x, ⬚, z) just shows up as f(x, ⬚, z) … just like the Lisp programmer I once meet, who didn’t like brackets and had an Emacs mode not showing them – Scheme looks surprisingly much like Python without brackets 
.
1 Like
Thanks for the compliment! I can only wish to be so lucid 
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?
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]...).
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 _.
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.
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.
1 Like
Seeing that /> and \> as proposed are mostly redundant with |> with _ as argued, the instinct is to choose one.
For the following discussion I will refer to tight _ currying as “placeholder syntax”, and /> and \> as the “fill operators.”
Considering that placeholder syntax and fill operators work to make different things convenient, the question becomes which things ought to be more convenient. Here’s an overview of the differences.
Piping/Chaining
Placeholder syntax requires a couple more characters, but can curry into any argument location as easily as any other:
x |> filter(iseven, _) |> join(_, ", ") |> myfunc(a, _, c)
Meanwhile the fill operators require a tad less thought, until you want to curry into a position that’s not at the front or back of the argument list.
x \> filter(iseven) /> join(", ") /> a /> myfunc(c)
So the question is raised: How frequently should we wish to chain an object into the first or last argument, versus arbitrary locations?
Extra Comments:
It can be argued that a benefit of the fill operators will be to encourage smart argument orderings which place important arguments near the front or back of the argument list.
Also, it seems like the fill operators will likely make autocomplete work better, as method signatures can be searched with one or more arguments already specified while the function name is typed out.
If you’ve tried
?(x, <tab>in the latest Julia REPL you’ll know it’s not a good experience (but maybe that’s temporary).
Partial Function Generation
Both placeholder syntax and fill operators yield a partially evaluated function.
Placeholder syntax requires all-but-one arguments to be known and yields a single-argument function:
f(_, a, b, c) ≈ x->f(x, a, b, c)
while the fill operators do the opposite, requiring one argument to be known and yielding an all-but-one argument function:
x /> f ≈ (a, b, c)->f(x, a, b, c)
These roles seem complementary in a way.
Similarity with Other Languages
Similarity with other languages shouldn’t be the primary reason for a feature, but it can be instructive to look at what has already proven useful.
The proposed placeholder syntax functionality is similar to Scala’s placeholder syntax.
Meanwhile, the fill operators’ functionality is a superset of Clojure’s relevant threading macro behavior (also Lazy.jl’s threading macros); it is also a superset of D and Nim’s UFCS behavior, as well as the relevant behaviors from OOP languages’ dot-notation method calling.
Scala has both: placeholder syntax and OOP-style dot-notation method calls.
Thoughts? 
P.S. To play and experiment with these options, we currently have:
- Placeholder-like syntax: DataPipes.jl, Pipe.jl, Chain.jl, and Underscores.jl (there are many caveats, nuances, and differences, depending on the package)
- Clojure-like threading macros: Lazy.jl
- Fill operators: @bertschi’s experimental peace pipe macro (frontfill only, using
++instead of/>, no broadcasting for now)
Let me know if I missed anything! 
1 Like
Just a minor point, _ would be partial application and not currying. The difference is subtle though and Wikipedia somewhat confusing on that issue. In a nutshell, currying refers to the transformation of a multi-argument function into higher-order functions with a single argument each, i.e.,
f(x, y, z) = x+y+z # multi-arg form
h = x -> y -> z -> x+y+z # curried form
Curried functions are particularly suited for partial application as arguments can be passed one-by-one, i.e., z -> f(1, 2, z) vs h(1)(2) as the corresponding forms for partial application.
Ok, enough wisenheimer. As most of the discussion seems to be about a concise syntax for partial application now, i.e., either using _ or the fill operators, I start liking this notation:
[1,2,3] |> ⬚->filter(iseven, ⬚) |> ⬚->map(sqrt, ⬚) |> ⬚->sum(⬚)
# or if you must use a macro
macro λ(app) :(⬚->$app) end
[1,2,3] |> @λ filter(iseven, ⬚) |> @λ map(sqrt, ⬚) |> @λ sum(⬚)
After all there must be a reason why Julia supports Unicode 
.
Unfortunately, I cannot support this proposal. I don’t even know which character is ⬚.
Okay I found out it’s \dottedsquare. Maybe if it had a shorter alias…
Looking at Base.Fix1 and Base.Fix2, there’s a lot of overlap between the proposed operators and the internal fix functions. If Fix1 were opened up to accepting more than one argument, it’d be completely equivalent to />. And for two-argument functions, \> is equivalent to Fix2. In other words, the proposed operators /> and \> are simply the logical extension of Fix1 and Fix2.
The only thing missing would be parametric types. Perhaps introduce parametric types FixFirst and FixLast, and then make /> and \> syntax sugar for them?
For example, in namedtuples.jl line 104 I see:
NamedTuple{names, T}(map(Fix1(getfield, nt), names))
with the proposed operators this could be written as
NamedTuple{names, T}(map(nt/>getfield, names))
and presumably, you’d see something like this:
julia> nt = (a=1, b=1.0);
julia> typeof(nt/>getfield)
Base.FixFirst{typeof(getfield), NamedTuple{(:a, :b), Tuple{Int64, Float64}}}
julia> nt/>getfield(:b)
1.0
similar for \> of course:
julia> arr = [1, 2, 3];
julia> typeof(arr\>map)
Base.FixLast{typeof(map), Vector{Int64}}
julia> arr\>map(x->x^2)
3-element Vector{Int64}:
1
4
9
As mentioned, having a parametric type that embodies partial application
One can also conceive a Base.Fix{n} where {n isa Int} type… or for the truly deranged, Base.Fix{k} where {k isa Symbol} for currying into keyword arguments. I’m not sure what’s a good way to make a type that would cover underscore currying. 
1 Like
I’ m working on an implementation like something in Goland 
in vscode extension. If anyone want to try out, please see Release A quick dot methods completion demo · xgdgsc/julia-vscode · GitHub . Welcome opinion/bug reports.
6 Likes
We are thrilled to announce the release of REPLference.jl, which was created in response to this thread. After months of development and testing, we are proud to present a package that solves the problem initially presented by @gianmariomanca in this thread. This will make it easier for beginners to learn and approach Julia (and hopefully it solves your problem @gianmariomanca).
It is worth noting that this package was not developed overnight. Instead, we undertook a rigorous and comprehensive process of testing every object with every name generated by the script that generates all documented names in the Julia programming language. This ensured that we created a package that is comprehensive and returns every name that can reasonably be called on an object.
However, we acknowledge that this is just the beginning and that we need the support of the wider community of experts and contributors to refine and optimize this package to meet the needs of beginners who are just starting with Julia. We welcome feedback and ideas from those interested in contributing to the continued improvement of this package.
Our ultimate goal is to provide an easy learning experience for beginners entering Julia, and with the help of the wider community, we are confident that we can achieve this. So, we invite you to download and try out this package and let us know how we can make it even better.
5 Likes
This is very good indeed, it basically brings the (spirit of the) old unix man to inside the Julia terminal working with all the already existing machinery.
1 Like
It doesn’t seem to work for the OP:
julia> using REPLference
julia> f = IIRfilter(0.9);
julia> man(f)
ERROR: MethodError: no method matching man(::IIRfilter)
julia> fun(f)
ERROR: MethodError: no method matching fun(::IIRfilter)
As stated in their docstring, it currently only works for Julia stdlib types, or types that are subtypes of those types:
help?> man
search: man Main mean DomainError maxintfloat median MathConstants macroexpand
man(obj::T)
man(obj::Symbol)
Prints a long text that explains what obj generally is in computer
programming and how it is implemented in the Julia programming language.
Note that T can only be a Julia stdlib type or a composite type that is a
subtype of a Julia stdlib type. If a type that does not meet these
requirements is used, an error will be thrown.
Examples of using man can be found in the docstrings of REPLference, using
the help?> mode.
The reasoning behind this is that, how does man knows what IIRfilter is about? It could have decided to simply load the docstring of types not in the stdlib, but the approach man takes is that it explains the concept generally in programming and then show how its used in Julia. As for fun, it’s self evident, one won’t know the methods to call on a type except a package author has provided a list for it.
If you feel this should be better in a different way, please open a PR with your ideas @uniment and I would greatly appreciate.
Seems nice, but I don’t understand how this package has anything to do with this thread…
2 Likes
Initially the author of this thread said beginners have a hard time finding new methods to call on an object, that’s why the package was created.
I know the thread has diverged a little bit to chaining rules, but the package was created in response to the original thread of the author.
1 Like