This example is not the real world case. I think there are other situations like case/cond that will break the original pipe operater into parts, which I dislike when coding in such a flexible language.
cjen07
0
cjen07
And if you look into the source code of param_pipe, despite it is short, perhaps, you will find it is hard to understand (in your words, completely indecipherable) unless you are familiar with Macro.unpipe
0
josevalim
Creator of Elixir
I think there is some confusion between readability and familiarity. Of course a construct someone is not familiar will be unreadable to most.
The trouble with this proposal is that it puts the burden on reading code even when I am familiar with the construct, the pipe operator. When I read the examples above, I need to manually unwind the operator and place the argument on where it needs to be. It prioritizes writing code over reading code and that’s a trade-off I would hardly make.
Every time I want to pipe to another argument, I write a private function and give it a decent name. No shortcuts. And the final code will read better too.
5
cjen07
You are certainly right, I will try to make an improvement in such a direction. I think assigning a variable within this pipe operator is at least an update/improvement of this library, just in another direction, after all I spent a whole afternoon in adding this. Much more to be done. 
0
cjen07
cjen07
fix a bug, more tests added, assigning a variable when piping into anonymous function is supported, Erlang 20.2, Elixir v1.6.2
I appreciate anyone who is willing to contribute or to find more bugs 
1
fcabouat
I think Clojure’s solution is quite elegant here : it has → and ->> (thread-first and thread-last macros) and as-> (kind of a mix between compose and a let-binding). It also has some-> and some->> (null-safe piping) and cond-> and cond->> (conditional piping).
|> and |>> might be enough compared to the possibly not very readable |n>
1
cjen07
I don’t think Clojure way is elegant, and is just syntax-level. I think readability is important but I think it refers to the whole code and the module orchestration. When you read code with proper readability, you can easily tell if some piece of code is relavant or not to your task.
Anyway, parampipe 0.2.0 that confroms with elixir 1.7.3 is published
1
Sanjibukai
Hello @cjen07
What’s the status of this project?
When I started to practice more and more Elixir, I immediately found myself in the same need.
That is, using an indexed pipe operator (it was the name that came into my mind).
Indeed, one of the use case I thought was when transforming data (usually done with functions that take the data as a first argument) and then finishing with a kind of a final function (like write, save and the like) that takes the data in other place than the first argument.
I also found that many functions from erlang modules could take what usually is the first argument on elixir side functions in the last position..
So I just did a google search for elixir indexed pipe and without surprised it gave some results, this post being the first.
I read the thread and I should admit that many points (e.g. the ones from @NobbZ) are relevant.
For example in a transformation pipeline (where until the end every function take the data as the first argument) there is usually a write/save like function which takes the data in other position..
Well it makes sense to break the pipeline here since there is a change in the “semantic”..
I mean, saving the result is not anymore about transforming the data.
So having an extra line better translates the intent.
Anyway, in my thought here is how I thought about this indexed operator:
- First, definitely indexed at 1.
|1>being the default|>.
So the operator would have make sense only starting from|2>.
Obviously it should be fully compatible with piping before or after with the default operator. - The
|$>(symbol usually synonym of ending like in regex, vim etc.) for piping as the last argument no matter how many argument the function is taking. - The
|#>(symbol for ignoring like in comments and because it has some kind of stroke effect) could have been used as a discarding pipe operator.
This could definitely bring some confusion since the following function call will need the full set of its arguments.
So what could have been the purpose here? Maybe if there is a need to produce a side effect like sending a notification or setting a flag (though I agree that this does NOT suit AT ALL the pureness of functions of FP paradigm) while it’s necessary to continue the pipeline with the previous data unmodified..
I wanted to learn more about meta programming (still never practice macro, quote, unqote and the like) to experiment around this idea..
However as I said I’m not sure anymore if this will not be more confusing than useful (particularly if it’s not a native functionality accepted by everyone).
Anyway, I still find this idea very great and might be interested to try your package in some projects to see if it might help or confuse in the long run..
So just wanted to have some news..
Cheers..
0
cjen07
hello @Sanjibukai ,
Currently, I am doing timeseries algorithms using python and c++ (because of work), and it’s been almost a year since last time I did serious elixir coding.
I have read your thought, that’s really interesting!
Feel free to add features to the project in any way!
Meta programming is fantastic and exciting and is quite next to program synthesis, the Holy Grail of computer science.
Hopefully you will benefit a lot from it.
Sincerely
Wang Chen
1