Genuine question, as I'm not up to date with C#'s recent developments: can C# do 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.

Or this variation:

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

It's currently badly outdated. There's one specifically for the UCS at https://ucs.mlscript.dev/

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

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.

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

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.

As mentioned in a response to a sibling comment, we plan to support `or`, which should address the problem you mention. (If not, would you have an example of what you mean?)

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

Indeed, and it was until very recently a source of unsoundness: https://icfp24.sigplan.org/details/mlworkshop-2024-papers/8/...

Oh, wow, that's interesting.

We added pattern matching and exhaustiveness to Dart not that long ago, and dealing with exhaustiveness and mutability was a big concern since Dart (unlike more strictly functional languages) generally doesn't avoid mutability.

Our solution was that whenever a pattern accesses a property, the language implicitly caches that value. Any future accesses to the same property in that switch statement/expression use the previously cached value. That way, an entire set of switch cases is always operating on an immutable snapshot of data so that exhaustiveness can't be violated by side effects. Spec:

https://github.com/dart-lang/language/blob/main/accepted/3.0...

We definitely want to get into that! Unfortunately it's not completely straightforward. A simple desugaring doesn't work due to our support for intermediate bindings and computations, which we don't want to recompute.

Do you mean something like compiling

  if (x is Left(Foo(y)) or x is Right(Foo(y))) and (y<5 or z>2) then 5

and destructuring Foo(y) only one time and dealing with parentheses?

Here the `Allocate` effect is just a syntactically-lightweight way of doing dependency injection, right? Similar to a Haskell type class. I don't see why you'd need to make it an algebraic effect, as it does not need to mess with control flow AFAIK.

It could fail.

That's obviously nonsense.

Java, one pair of parens:

    int x = 1;
    int y = x + 1;
    System.out.println(y);

Clojure, six pairs of brackets:

    (let [x 1 y (+ x 1)] ((. (. System out) println) y))

Your idea of what FP means is completely nonstandard.

For the record, there is not one accepted definition, but we can get close by saying that FP languages are those based on lambda calculus as their semantics core. And the primary mechanism in lambda calculus is variable capture (as done in closures).

C is based on the Von-Neumann model and has absolutely nothing to do with the lambda calculus. No reasonable PL expert considers it functional.

They almost certainly run into these issues, but like most of the community, they probably think the cost is well worth bearing, given the advantages the language gives you.

Once you're used to the way it works, and if you're using well-maintained libraries, I find that it's really not such a big deal. Though it's always awkward to have transitive dependency conflicts, and those are best avoided if possible.