[lptk]

Just check out the paper's Motivaton section (2).

In ML you can't write something like this:

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

where the `...` may include many cases and may contain other Lit cases, so that you would need to refactor the whole expression.

Haskell's pattern guards can do this, but they can't "split" control-flow in the middle of a case, as in:

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

but these all fall out completely naturally in the UCS.

Also, exhaustiveness Just Works without the need of any type annotation. The system is actually type system agnostic.

[lptk]

PS: there's another point being made on Reddit about cond's right-shift problem: https://www.reddit.com/r/ProgrammingLanguages/comments/1g127...

[halostatue]

Thank you. I think that I’ll need to read this again with that particular comment in mind, because that makes sense.

The limitations of Elixir syntax means it would need to be something more like:

    ucs do
      expensive() =>
        and cheap1() -> "branch 1",
        and cheap2() -> "branch 2",
      cheap3()       -> "branch 3"
    end

There are other ways around it, but it could be fun to try to build a macro in Elixir for the UCS.