Enable |> to create a function when given of two.

[lucasb-eyer]

That means, f |> g creates a function which, when applied, first
applies f to its arguments and then g to the result of f. This is very
useful to create functions for map/filter:

map(sin, map(cos, map(sqrt, [1 2 3])))

or

map((x)->sin(cos(sqrt(x))), [1 2 3])

become

map(sqrt |> cos |> sin, [1 2 3])

which is much more readable imo.

And for a real-world use:

map((fname)->float32(imread(fname)), image_filenames)

becomes

map(imread |> float32, image_filenames)

[gitfoxi]

Cool. But I wonder if you haven't gone too far enough? I find myself defining |> with partial in ad-hoc ways to do things like:

readall() |> matchall(r"\d+") |> int |> sum |> println("Sum: ")

But I haven't found a generic way to do it. Also, in my dreams it would be lazy rather than readall() the entire stream, just going chunk by chunk, matching a few, suming cumulatively and so on. I guess what I'm saying is that I want the good parts of Haskell but not to learn the meaning of Monad, Monoid, Functor or Applicative.

[jiahao]

I'm not convinced of the usefulness of this method in general, since the notation is nonstandard and it is very easy to define it yourself in your own code.

[JeffBezanson]

There is already a bit of a convention that x |> f does f(x).
On Dec 26, 2013 12:14 PM, "Jiahao Chen" [email protected] wrote:

I'm not convinced of the usefulness of this method in general, since the
notation is nonstandard and it is very easy to define it yourself in your
own code.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5236#issuecomment-31227888
.

[lucasb-eyer]

@jiahao @JeffBezanson Yes, I didn't invent this, just extended the "builtin" |> by a method for when both arguments are of Function type.

@gitfoxi yeah, it being lazy would be cool, but I think that needs a whole different machinery.

[JeffBezanson]

I think it is too confusing for an operator to mean application some times
and composition other times. These are not variants of the same behavior,
but exact opposite behaviors.
On Dec 26, 2013 1:26 PM, "Lucas Beyer" [email protected] wrote:

@jiahao https://github.com/jiahao @JeffBezansonhttps://github.com/JeffBezansonYes, I didn't invent this, just extended the "builtin"
|> by a method for when both arguments are of Function type.

@gitfoxi https://github.com/gitfoxi yeah, it being lazy would be cool,
but I think that needs a whole different machinery.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5236#issuecomment-31230261
.

[lucasb-eyer]

To me they feel the same: x |> f |> g sends x through f and then g ; since x is a number, the evaluation does happen. Now just doing the f |> g part results in something (a function) which, when x is sent through it, is the same: if a = f |> g, then x |> a should be the same as x |> f |> g. It just feels logical to me that it would support this kind of factoring.

In the end, f |> g really does f(g), it's just that if g is a function, it still needs an input itself. (And thus cannot be an execution yet.)

Now, I do get your point, and if you think it's too confusing for most people or doesn't fit julia, so be it :)

[JeffBezanson]

Type-based dispatch is simply not appropriate here, because a function can
be an argument to another function. Our friend Mr. Church might be
surprised to hear that application and composition are the same thing.
On Dec 26, 2013 2:07 PM, "Lucas Beyer" [email protected] wrote:

[StefanKarpinski]

You wouldn't like Alonzo when he's mad.

[gitfoxi]

Aw Closed. We were having such a nice circle jerk.

On Thu, Dec 26, 2013 at 1:14 PM, Stefan Karpinski
[email protected]:

You wouldn't like Alonzo when he's mad.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5236#issuecomment-31236095
.

Michael