hauleth
Simple and clean library that is inspired by discussion in Elixir’s issue tracker and uses operator suggested by @josevalim (however it may change, other operator that I was considering was &_)
Short example of how this works:
# Old pipes work as it have been before
iex> 5 |> Integer.to_string()
"5"
iex> 5 |> Integer.to_string(2)
"101"
# You can use `...` to mark the point where the expression should be inserted
iex> 5 |> Integer.to_string(10, ...)
"20"
For now it works only with function calls, so unfortunately no support for stuff like {:ok, ...}, [..., 2], or %{a: ...}. It also do not work with things like 1 |> struct(URI, port: ...) as the ... operator must be top level.
I wanted to create another one (the other one is @Qqwy’s CapturePipe) to test out using another operator, that would be IMHO less confusing than &1 in CapturePipe.
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
bluejay
Nice work. It might be obvious to others, but you may wish to add in the docs that you need to
use Magrittenotimport Magritte.hauleth
Yes, I am still writing the docs to be clearer on the usage.
Qqwy
I’m very eager to see how this will develop. CapturePipe has two disadvantages, both related to the fact that
&is already used in a somewhat different way in existing code:&will be shuffled around, so it will very much clobber the pipelines that contain it.Magritte has neither of these disadvantages. I personally do not like using
...as chosen ‘fill in’ argument that much because it is used in many other programming languages to stand for multiple (e.g. variadic) arguments. I’d definitely be a proponent of using&_. This still does need some thought (unless a new dedicated token is added to Elixir for it) because whilefoo(1, &_, 3)works fine,&_ + 2will be parsed as if it was the (nonsensical) capture&(_ + 2). Maybe there is a way to deal with this gracefully, I don’t know at this time.hauleth
I was also thinking about
^_which would bind stronger than&_, but would be surprising behaviour once again, as it is “non standard” usage of^operator.hauleth
For anyone interested, I have created small GitHub Poll about which is the preferred operator for such “here be dragons” behaviour in
|>:https://github.com/hauleth/magritte/pull/1
I would
to hear your opinions.
shd42
Since it’s directly related to the capture operator, i’d argue that anything who doesn’t contain
&would cause more confusion, after all, it’s an “extension” of the current behavior, so it should stay on track with what it uses now. I’m not sure that i’d like&_, but at least, it keeps consistency with the overall use of this operator.Note: I’ve clicked on
, but my vote goes for
...in your poll, because i didn’t realise it would not open a page for me to select an option&_.josevalim
I like
...honestly.&is already overloaded, so sometimes I worry about adding new meanings....is relatively safe, doesn’t cause precedence issues, and is unlikely to be used as a variable.hauleth
Thanks for pointing this out, I have added the info in top post.
That was my reasoning for this choice as well. I just wanted to know what others think about it.
shd42
To me, this is simply a consistency point of view, it really looks like using a completely different operator, with “only” the objective of extending the capabilities of what’s already there. It’s like having two different syntax to, in the end, do something quite similar to what the capture operator already does, hence why i though that using something like
&_was a better idea.The
&issues means that it’s better to just put it out of the options ?lud
...could be a variable !?