[macintux]

It's unfortunate when I encounter a language that has a crippled implementation of pattern matching (looking at you, Scala). After using Erlang, it's hard to accept anything less.

[vram22]

How are F#'s and OCaml's implementation of it, in your opinion?

[macintux]

I’ve not tried either, although in my limited exposure to SML it seemed fine.

The other related feature whose lack I regularly lament in most languages is multiple function heads, which apparently is rarely used in the ML family tree, bafflingly.

[sgrove]

I haven't heard the term "multiple function heads" - is it similar to Haskell's way of defining functions? e.g.

    fib 0 = 0
    fib 1 = 1
    fib n = fib (n-1) + fib (n-2)

[yosh]

Yeah, this is Erlang:

    fib(0) -> 0;
    fib(1) -> 1;
    fib(N) -> fib(N-1) + fib(N-2).

[rad_gruchalski]

But these are all compiled into, essentially, a giant case statement. It’s a syntactic sugar. Your last line is missing a dot at the end.

[macintux]

Concise code is its own reward. Yes, it's syntactic sugar, but there's a reason syntactic sugar is valuable.

Even if performance is the same, you wouldn't prefer this Javaesque code:

    Int.from(8).multiply(5)

You'd use `8 x 5` were it available.

Several discrete function heads are easier to mentally parse than a long case statement because you know without a shadow of a doubt that there's no code in the function above or below the case statement, and you always have all relevant bindings directly adjacent to their usage.

Consider this Erlang code:

    f(X, Y) ->
       case X of
          {1, 2} ->
              low;
          {2, 4} ->
              high;
          {3, 6} ->
              Y
       end
    end.

When you get to the 3rd case statement and `Y` appears, it's jarring because it was declared several lines removed.

Instead, this code makes it explicit for each function clause that we don't care about the 2nd argument, and when we do care, it's immediately obvious where it came from.

    f({1, 2}, _) ->
       low;
    f({2, 4}, _) ->
       high;
    f({3, 6}, Y) ->
       Y.

[macintux]

Exactly. I don’t know what the typical industry term for it might be.

[mercer]

Multiple Dispatch / Multimethods (I think?)

[macintux]

Interesting, it appears that multiple dispatch is accurate. Thanks.

[mgradowski]

Pattern matching!

[macintux]

No, it relies on that, but the creation of multiple function clauses via different matched heads itself isn't simply pattern matching.

[YorkshireSeason]

What's wrong with Scala's pattern matching?

[macintux]

I shouldn't have said "crippled." It's just much more limited than when used in Erlang.

From digging a bit it appears to be somewhat the JVM's fault[0] and quite a lot of it is simply that it's a different type of language from Erlang.

In Erlang, nearly every line of code involves pattern matching, regardless of whether the developer takes advantage of it or not. Every assignment statement, every function return, every function parameter, is an exercise in pattern matching. It's at the core of the language, not an add-on.

As I mentioned in another comment, a closely-related feature that really shows it to its full advantage is multiple function heads/clauses.

[0]: https://www.scala-lang.org/old/node/11982

[YorkshireSeason]

OK, I also don't like Scala's inability to deconstruct in the parameter list. I come from an ML background where that is possible. But I found it less bothersome in practise than I had originally anticipated.

Erlang has pattern matching on bits [1] which is convenient, that would be nice to have, especially when writing networking software.

[1] P. Gustafsson, K. Sagonas, Efficient manipulation of binary data using pattern matching.

[macintux]

Good point on the binary pattern matching. I’ve rarely used it, but it is quite powerful.

I was pleased to discover Python’s tuple pattern matching in function heads, only to be disappointed that it was removed in Python 3.