The Ultimate Conditional Syntax

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.

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.

Looks very similar to lambda zero syntax (https://github.com/clark800/lambda-zero):

    def getNaturalName(tag, globals)
        if globals.lookup("0") is Just(Global(_, _, term))
            if term is Numeral(_, type, _)
                return Just(Name(getTermTag(type)))
            error showSyntaxError("0 must be a numeral to use numerals", tag)
        return Void

Though this ultimate conditional syntax is more general because lambda zero only allows one destructuring per conditional to simplify parsing.

The other one I want occassionally is "or".

Imagine Left and Right contained data of compatible types, then I'd like to extract that data (regardless of tag) like so:

    if x is Left(y) or x is Right(y) then ...

That way I only need to write the `...` part once. (This could be combined with the rest of the pattern matching machinery in interesting ways, and would probably need to have eager matching / short-circuiting semantics in case both cases match).

They missed one:

    def agent(data, predicate, fns):
      ps = map(predicate, data)
      fs = map(lambda x:fns[x], ps)
      return map(fs, data)

Basically you want to apply one of N functions to each of the items in your data iterable, so you have a predicate to figure out which function to apply first. The degenerate case is when you have just 2 functions and your predicate returns a boolean (0 or 1).

This is "agent" from J: https://code.jsoftware.com/wiki/Vocabulary/atdot#agent

Elixir already has this - "with". https://www.openmymind.net/Elixirs-With-Statement/ E.g.:

  with true <- is_email_address?(email),
     true <- String.length(code) === 6,
     %EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email),
     nil <- EmailAddresses.get_email_address(email),
     {:ok, user} <- Users.create_user(data),
     {:ok, email_address} <- EmailAddresses.create_email_address(user, email) do
     ...
  else
     ...
  end

Kudos for publishing in OOPSLA, but alas I'm skeptical. This seems to add visual clutter/mental overhead as one needs to parse a decision tree rather than having a "flat" sequence of patterns with the optional when-condition.

Also,

> all the branches in the corresponding pattern matching expression would need to destructure the pair, even when only one of its components is needed

Can't one just bind the unneeded component to _ ? Isn't that actually a good thing, as it clearly self-documents we won't need that value on that branch?

There's an online playground for MLscript at:

https://hkust-taco.github.io/mlscript/

This is really cool

It reminds me a lot of the kind of flow you get in mathematics sometimes. I guess theorem prover languages may be keen to adopt it.

I'd be less keen in a language with side effects, unless the language has a way to restrict it to pure functions

I don't understand how it's better than traditional pattern matching.

I love this.

Not the implementation, I think one could do better, but the fact that they identified an interesting opportunity: coming up with the Ultimate Conditional Syntax for pattern matching.

I would love to see them take one more crack at it, and this time try to think about how to reduce the syntax to the bare minimum.

Here's my read/adding of this language to PLDB: https://www.youtube.com/watch?v=UzsDaq0UdnM

This is the ultimate conditional syntax:

  if (x === 1) console.log(“it’s 1”)

The “if” bothers me though, be nice not to have it.