I like that there is this left-to-right flow. I think it’s a bit nicer to read than if-let ordering where the pattern comes before the thing it will be matched against. I think it’s also good for ocaml-style constructor disambiguation, which tends to go in lexical order.

Another nice aspect of making guards a less special case is that it avoids complexities in deciding if a binding is unused. I believe this logic was a source of lots of compiler warning bugs in ocaml.

This syntax doesn’t seem to solve the following problem with matching where there are two paths to the same binding, (say you have an option in one branch but it isn’t optional in the other, and maybe you’d like to handle both cases with the same code. Currently you can do that with a match (match …) with … pattern.

I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem:

  type t = { mutable x : bool }

  let n = function true -> 1 | false -> 0

  let f t =
    match t with
    | { x = false } when ( t.x <- true; false) -> -1
    | { x } -> n x * 2 + n t.x

What does t { x = false } return? Similarly if you changed the second case to be two cases instead of binding x?

C# pattern matching gets very close. I think C# can do everything except for their last example ("splitting conditional prefixes in arbitrary places"). One of the things I miss when switching to Rust.

    if foo(args)
        == 0 then "null"
        |> abs
            > 100 then "large"
            < 10 then "small"
            else "medium"

That last syntax took me a while to parse in the paper, but I can imagine numerous places in our everyday code where such syntax would more concisely capture intent.

    if e is
      ...
      Lit(value)
        and Map.find_opt(value) is Some(result)
        then Some(result)
      ...

      ...
      Lit(value)
        and Map.find_opt(value) is Some(result)
        and computation(result) is
          Left(a)  then ...
          Right(b) then ...
      ...

Kudos to the authors. It takes some fortitude to try to make a contribution to something as fundamental and ubiquitous as the "if" statement. Appreciate providing the grammar and the thorough explanations, will save a lot of pain when trying to implement!

> Below, the code on the left is equivalent to the more verbose ML expression on the right:

Wait a sec ... ML has the pipe of Elixir? Damn, I didn't know that!

I like the brevity, but I don't like the (at least visual) need to indent or whitespace focus. I guess I am too much a sucker for S-expressions now. But a similar structure could probably be written as a macro in a lisp, avoiding any whitespace focus or even dependency on it.