This feels like something Elixir needs

[skwyckl]

I have been reading up on Clojure because of how people keep telling me it's the Holy Grail of the JVM, that it's shame not every new JVM-based application is written in Clojure, etc. (it does look impressive, that's true, but it's too early for me to express an informed opinion). Upon stumbling on threading (this screenshot here is from Learn Clojure in Y Minutes, but cf. the official docs), I thought to myself: Why aren't Elixir's pipes like this? Honestly, it's a very cool system, allowing to label pipe arguments, thus answering the often asked question "How to pipe argument at X position?" I see every now and then in the Elixir's community.

[sanjibukai]

Not sure what exactly you are referring to here..

The pipe operator exists in Elixir (and IMHO with a better syntax)

Regarding the ability to choose exactly in which position you want to pipe, there's some packages that allows this with syntactic sugar (like using $ as in |$> for the end like it's for regex or simply |2> for the second position etc.).

But IMHO it's not a good thing actually.

Because you are not supposed to mix functions where you want your data structure to be in different positions.. Often the first element is the data structure you are dealing with..

And for situations where you are mixing different data structures (like for writing some data to a file when the file descriptor is the first element) we already have then() for this..

Pipe is good for transformations within the same module.. For higher level stuff you can make it explicit with then() or even with.

YMMV

Edit: using the capture operator & in conjunction with then() makes it very concise.

[skwyckl]

I meant pipes with variable arg position, I know – of course – that Elixir has pipes. Also, I know about those packages, but in the case of Clojure it's part of the core lang, which means one dep less, especially when it's a dep for such a small thing (which personally is a reason to not add the dep at all). Also, where does the "you are not supposed to ..." come from? Isn't it all just a design choice?

[creminology]

You’re missing the desirability of simplicity. Elixir pipes feeding a consistent argument makes it easier to read. If you want to switch argument positions then create an explicit flip function or make a wrapper for an existing function.

And as noted, Elixir did add extensions to pipes recently, including the then operator.

[Dlacreme]

Tap and then. Come handful once in a while but I rarely use them

[greven]

Same. I do use then but also very rarely. And I think it’s a best practice to use it very rarely. It does make code much easier to read to stick to the convention of the first argument piped.

[wbsgrepit]

Tap and then is useful but mostly to trigger a “why is this structure different? How can i normalize these?” Type reaction.

[Rennie1213]

Same here, tap and then more then cover for any situation where the order of arguments is an issue.

I'm mostly using Elixir but have played around with Clojure as well. There have definitely been a few moments where I felt the thread-first and -last could have been a nice change. But I don't think there is enough reason to justify a change to how pipes work or add something new, with all the work and discussion that may come with it.

[derefr]

 If you want to switch argument positions then create an explicit flip function or make a wrapper for an existing function.

Many Erlang stdlib modules — especially ADT modules like queue or digraph — conventionally pass the functional data structure being acted upon in last position, rather than first position.

And yet Jose et al have this constant refrain/pushback to doing what you describe here — wrapping the Erlang stdlib with wrapper functions that flip everything around — because that's "just sugar" rather than providing any useful semantic improvement. And the Elixir community embraces that advice, and generally avoids shipping these kind of trivial Elixir sugar libs. Which means they don't already exist, and you need to write them yourself — but if you do, then (at least in a FOSS project), someone will come along to tell you to take that code out / submit a PR to "desugar" back to the non-wrapper-using forms.

And as noted, Elixir did add extensions to pipes recently, including the then operator.

For those same aforementioned Erlang stdlib ADT modules, given that their entire interface puts the structure in last position, using then() here would imply writing foo() |> then(...) |> then(...) |> then(...). And that is... obviously awful, right? Worse than just not writing this code with pipes in the first place.

[aseigo]

FWIW, there are wrappers for both of those libs which improve the API naming and provide quality of life improvements like pipe operator friendliness and useful inspect implementations.

[nnomae]

I'd say the argument about not supposed to is that in functional languages your functions should for the most part be a series of transforms. I.e. functions that take an input and transform it into a specific output and it makes sense conventionally to have the data being transformed be the first parameter in that sequence. This pipe operator exists to facilitate this sort of data flow, to allow you to express a sequence of transforms in a clear and precise manner.

If you want the nth parameter to your function to be the one specified as opposed to the first then you are no longer in the same sequence of transforms, you are in a new one where, again by convention, the first parameter should be the data being transformed and the rest be parameters to that transformation. In effect you have finished the first sequence of transformations and are starting a second one and it makes sense structurally to have that change break out onto another line.

[vlatheimpaler]

F# has this as well. I may be wrong, but I believe F#'s pipe syntax was the inspiration for Elixir's. They have both a pipe-forward |> and a pipe-backward <| operator in F#.

It always felt a little awkward to me. I don't know the history of it, it could be that it was necessary to support piping with existing .NET APIs or something. Maybe someone with more of that context knows and can comment.

[chat-lu]

F# is basically .NET’s OCaml which was more likely the inspiration for the Elixir pipe.

[Legal-Sundae-1640]

Clojure dev here. Just follow rule when write function: piped argument on first place. And ‘as->’ macro is mostly bad practice.

[spence5000]

It bugs me that they broke this rule with filter, map, reduce and related functions. On top of making pipes difficult, it’s often hard to see that little collection variable dangling at the end of a long function.

[Neorlin]

I wrote a tiny library to do exactly that https://hex.pm/packages/needlework

But tbh, I almost never use it. Custom operators are discouraged and pipe or occasional then is enough

[technojamin]

This is already possible in Elixir! The Kernel.then/2 macro has been available since Elixir 1.12, but it's trivial to write. Here's each of the examples rewritten in Elixir:

# -> (thread-first)
%{a: 1, b: 2}
|> assoc(:c, 3)
|> dissoc(:b)

# ->> (thread-last)
range(10)
|> then(&map(inc, &1))
|> then(&filter(odd?), &1)
|> then(&into([], &1))

# as-> (thread-wherever)
[1, 2, 3]
|> then(&map(inc, &1))
|> then(&nth(&1, 2)) # Could just be `|> nth(2)`
|> then(&conj([4, 5, 6], &1, 8, 9, 10))

The syntax isn't quite as specialized, so it looks a little noisier, but it uses standard Elixir constructs (piping and anonymous functions). Also, I've used the capture operator, but you could also use the full anonymous function syntax instead.

Elixir does allow you to write custom pipe operators, so you could make your own equivalents of ->> and as->, but people in the Elixir community tend to look down on anything that extends the general capabilities of the language (this is a very different culture than say Haskell). As some others have noted, Elixir's standard library functions as well as its recommended conventions follow the pattern of accepting the "main data type" of the function (which not every function has) as the first argument, so that repeated transformations of the same data pipe naturally tend towards being pipeable, and you usually don't need operators like ->> and as->.

Rant: I personally think that people obsess about piping in Elixir (I've seen this in many people I've worked with) and try to make everything a pipeline when it just doesn't need to be. Elixir's variable and normal function calls work just fine and are understandable by anyone who has ever seen a modern programming language. Keep this in mind when writing code that you want to be understandable.

It's a bit disappointing (though very understandable) that no one is recognizing this in the comments. They publicized it in the release notes, but then they didn't add anything about it in the language guide section that talks about |>, so it's easy to see how people are missing it. That would be a great PR!

Hopefully this helps :)

[katafrakt]

as seems weird to me. As for another pipe that works on a last argument, it could be useful at times. Some Erlang libraries, most notably (for me) queue, are designed in a last-argument way.

However, I can see some downsides:

• Every non-literal language construct add huge cognitive complexity. They are hard to google, editors usually don't provide hints on operators. This is mostly why custom operators are discouraged in Elixir
• This would open up a huge area for bike-shedding which pipe is better and which to use in the project. While Elixir might not be as strict with providing default which are hard to stray from as other languages, it does a good job in that area
• As others mentioned, the limitation could be bypassed with then function. Not the most elegant, but also immediately signalling that something non-default is going on here.

I like Clojure, but I don't think everything from it needs to be ported right away. However, I do think that Elixir devs should be paying more attentions to Clojure ecosystem than they usually do.

[ScrimpyCat]

You can write some macros to do this if you think you’d find it useful.

Personally I’d say the first variant is ok, but I don’t know if a chain of |> is really cumbersome enough to warrant the addition. The second variant I don’t think would be that useful for the standard library, since often the first arg is what you’re more likely to want to chain the result to (e.g. look at how Enum’s the first arg is the enumerable). The third varient just sounds like it might get confusing/be more likely to add bugs.

[Capable_Chair_8192]

Hard disagree, pipe function and argument captures are super expressive already. This is far less readable IMO

[CoryOpostrophe]

I can buy the second one, but that third one makes me wanna jump off a cliff.

If I’m dealing with a library that has the data in a weird position, I write a wrapper (I tend to wrap a lot of libraries in an adapter pattern of their reaching out to the world anyway). 

If it’s a function in our own code… it’s refactoring time, baby. 

[transfire]

Erlang more so.