With traditional matching there are up to five different things:

- if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is

- match e with { p -> e }. This is the classic pattern match case

- if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ())

- match e with { p when e -> e }. This is matching with a guard but I’ve counted it as a special case because it doesn’t easily designate into a match because of the binding/evaluation order, and the guard is special because it can only go at the top level of the match clause so it isn’t just a special kind of pattern (though maybe it could be)

- let p = e. This is one-case pattern matching used for binding variables or destructuring.

The paper proposes a way to make the first four cases obvious parts of one more unified thing, which makes the language potentially simpler and may reduce some weird warts like where guards can go.

There's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.

I totally agree that can be the case, but I’m not sure it applies that much to the OP.

Sometimes a simple conditional statement grows into something more complex over time and it's nice to keep the same malleable syntax, particularly (as is the case of the article) with good semantic and performance guarantees.

After a few years working in Haskell as a hobby, I came to the conclusion that complicated pattern matching is an antipattern.

I didn't think of it this way at the time, but my current belief is that complicated pattern matching is an extremely tight coupling to what is being matched, and that's not a good thing.

I'm not convinced super powerful pattern matching is even a good idea. I think a lot of the love people have for it is precisely their joy at being about to introduce tight coupling with such syntactical convenience. Syntax affording tight coupling is not a good thing.

(Simple pattern matching, especially on branches of a sum type, is fine and useful, especially when you are doing it precisely because the code will need to be changed if the sum type adds or subtracts other branches, and this need comes from something "real" and not merely false coupling. But the deeper in you go with the pattern match the more whatever it is you are reaching in for should be abstracted out into a function.)

I agree. I'm generally bearish on any language constructs that are difficult to implement. If it's difficult to implement, that probably means there are subtle edge cases that will manifest in confusing behavior at both runtime and compile time.

Inspired by duality, I've been trying to work out a language where there's a more obvious correspondence/symmetry between expressions (which evaluate in an environment of named bindings to produce an anonymous value) and patterns (which destructure an anonymous value to produce an environment of named bindings).

Have you made any progress?

In theory, yes: I've used it to derive a (minor but accepted as published) patch to a Turing Award winner's paper; in practice, no.

[the semantics haven't changed much over the past years, but the syntax? even as a single person, who ought to be able to come up with a unified design, my different temporal instantiations insist on bike shedding]

Also check out my other answer here: https://news.ycombinator.com/item?id=41901573

I like overloading most of the time but prefer specialized syntax for the various conditional idioms. Encapsulating it all in one keyword makes "if" harder to parse.

It looks like it could be more concise sometimes. For instance, you could have this:

  if f(x) is Some(a) and g(x, a) is Some(Right(b)) then h1(a, b) else h2(x)

The equivalent pattern matching with a match expression in pseudo-ML:

  match f(x) with
    None -> h2(x)
    Some(a) ->
      match g(x, a) with
        Some(Right(b)) -> h1(a, b)
        _ -> h2(x)