I’m still not decided on how much I love it, but I have noticed that when I go back to try and write some code in Elm or Rust that I have to reorganize how I think about defining functions for various situations, usually by wrapping the arg in some Enum (Rust) or custom type (Elm) and then using a match or case statement in the body of the function. If I start to get nested matches I really start to appreciate the Elixir pattern. Even though the nested matches are probably a sign that I’m poorly designing my project to start with I can appreciate that Elixir provides a way to keep that code clean.
stevensonmt
tadiou
The thing to me, specifically about pattern matching during function overloading is that it really gives both elixir/erlang it’s own feel.
When I first started learning Erlang I was like “okay, where’s the currying here? why aren’t we doing partial application” as I was coming hot off a tour of duty with OCaml and then it took me about a year to realize that I was reaching for a tool that didn’t need to exist in Erlang (and ultimately Elixir), because it’s just organized in a different way.
I think the thing for me that feels most useful is that you’re clearly defining the boundaries in the function signature, trading explicitness for composability. Granted it’s absolutely a scale on both of those, but Ex/Erl tends to favor the former vs the latter.
3
Sebb
excuse the stupid question, but how does pattern matching in function signatures replace partial application?
0
hauleth
I am fully aware of that. Same goes for Rebar3 AFAIK.
I never said that it is like Mix, I just said that a lot of languages try to have unified build and dependency management tools, as these have proven their usefulness for the developers (and became bane of the OS package repository maintainers).
1
tadiou
I’m just thinking when I write OCaml code, the pattern matching exists as the body of the method, not the signature, when we do pattern matching especially with doing partial application in Ex/Erl, it can live in the signature, which allows us to provide iteratables as well that are specific to the information at hand, even though Ex/Erl doesn’t really do partial application. I mean, sorta.
Because y’know (oh god this is gonna be bad bc my brain is broke right now)
def something({:ok, file_type: "json", whatever}), do: fn (x) -> whatever(x) |> JSON.something; end
def something({:ok, file_type: "xml", whatever}), do: fn (x) -> whatever(x) |> to_charlist() |> :xmerl_scan.something;
end
gives us the ability to apply the function as part of the condition, where x might be a file? some sort of data here. Lazy operating? maybe Instead of doing the conditional inline like
(* i'm not gonna plug this in and figure the type *)
let something file_type whatever =
match file_type with
"json" -> whatever |> Yojson.something
"xml" -> whatever |> xml.something
;;
You can see that in some like Enum-ish related concepts a lot more that deal with polymorphic types more than anything else.
But it’s not that it replaces necessarily, it just moves the responsibility into the forefront. That was probably the biggest difference for me was that you’re improving clarity by adding relevant data to the method signature instead of putting it in the body.
It’s a code readability thing more than a “it replaces”.
3
APB9785
Creator of ECSx
All types of pattern matching, but especially in function definitions.
Also the pipe operator.
Two things I hate not having when I have to use another language.
1
wojtekmach
Hex Core Team
My favourite Elixir features are pattern matching, macros, and tooling (Mix, IEx, ExDoc, etc). I like to share this article: Elixir · How I Start. as it shows some language basics but more importantly supervision trees and distribution.
6
dimitarvp
Same, this made me organize my Rust code by making smaller functions covering part of the case arms. Since Rust can’t do pattern matching in the function heads I end up making those functions with different names – which I’m not sure yet it it’s a good pattern or not.
0
stevensonmt
That’s why I end up wrapping args in Enum variants.
enum Bar {
BarString(String),
BarNum(i32)
}
fn foo(bar: Bar) -> Result<i32, std::num::ParseIntError> {
match bar {
Bar::BarString(x) => x.parse(),
Bar::BarNum(y) => Ok(y)
}
}
0
dimitarvp
Yep, me too, although more often than not I just make functions that describe a part of the logic chain with their suffix.
2