An F#-like operator |> would be useless without a convenient partial application syntax. Macro-like operators aren't well received in Erlang, certainly not when they obfuscate what really is going on.

really useless?

http://joearms.github.io/2013/05/31/a-week-with-elixir.html -> "The Pipe operator"

I really get several arguments against such "syntax sugar". I would not call it useless, though.

So how to handle/structure/avoid code with function call chains in absence of such operators?

First, I am never against adding good syntax into a language, I implemented the named funs. Second, just because Joe says something doesn't mean I agree. Third, here is my tentative answer to the piping syntax:

An F#-like pipe operator:

    X |> F.
    F(X).

A partial app syntax:

    fun map(F)/1.
    begin _1 = F, fun (_2) -> map(_1, _2) end.

These coupled together allows concise yet explicit function chaining and makes use of the most common convention which is to pass the most-changing argument last.

The problem with what Joe likes is that in X |> foo(bar), the call foo(bar) is transformed to foo(X, bar), making what really happens less obvious, a big no-no for Erlang.

Kudos for the named funs.

Care to provide some "marketing" about what they allow for? (besides and in addition to what is already in the eep-0037(?))

Why are they important? How will they support developers in writing and understanding erlang code? Do they provide even some internal/resp performance benefits?

Reg. the piping syntax: how is your proposition making the "transformation" more obvious for the reader of some application code?

To me it seams partial appl. is the more powerful feature for sure. Together with a rather "simple" |> operator it could provide the fun piping functionality. It looks like a map function is needed to wrap other functions taking part in the piping, right? Is that the "make it obvious" part you mentioned?

The piping syntax from elixir (from the joe blog above) on the other hand binds the |> operator to a more specialized, less flexible "fun call" transformation providing fun piping only, right?

Anyways, thanks for insights and again really kudos for the named funs.

With my two orthogonal syntaxes, there is no transformation. "|>" doesn't need to look at its operands to be implemented. With a macro, you have a call to foo/N end up a call to foo/N+1.

Also, coming from a functional background, where I read "X |> F()", I think "(F())(X)", not "F(X)".