By the way, metaprogramming/abstraction means less code but same functionality. Readability, I think, is not the only goal or even the goal in this process, similarly, I donāt think while(n < 10) cout << n++; increases any readability.
If the first time you learned the syntax &(&1), and you think it increases any readability than (fn x -> end) , I will apologize.
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.
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
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.
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.
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>
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
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ā¦
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.
This bring me several memories (as a former EE engineer worked a lot with signalsā¦)
Yes Iām pretty convinced of thatā¦
Yet when I jumped into ruby (from assembly/c) I was astonished by Ruby meta-programming abilitiesā¦
And Iām sure that it will be ever more interesting in elixir.
Iām just taking the time to embrace FP before going onā¦
Frankly speaking, I find the parametrized pipe hard to read and understand, so I donāt really have an intention to use the library. Having said that, I applaud your persistence and Iām very happy that Elixir allows you to even do these things!
On a side note, I think an explicitly āindexedā pipe would gain my interest (Iām looking at you File.write). Something like:
data
|> foo(1, 2) # pipe into the first argument
|>> bar(4, _, 6) # pipe into the second
So the idea is here that thereās a new operator and I can explicitly state which argument I want to pipe into. The |>> is far from perfect, since it breaks the alignment.
