lptk · HackerTrans

2 lata temudiscuss

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 ...
      ...

lptk

2 lata temudiscuss

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

lptk

2 lata temudiscuss

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

lptk

2 lata temudiscuss

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

lptk

2 lata temudiscuss

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

2 lata temudiscuss

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/...

lptk

2 lata temudiscuss

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.

lptk

4 lata temudiscuss

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.

lptk

4 lata temudiscuss

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))

lptk

4 lata temudiscuss

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.