JavaScript Pattern Matching Proposal

So I'd take it more as "You know this mediocre compromise we had to do because JS is missing this core language feature? Well, there you go".

Would love for this to land :-)

a. Yup, that's what it's called in OCaml, Scala, F#, etc. Might be a little confusing at first, but it's all about finding a "match" for your value, which is different from a guard in an "if" or a "switch".

In an "if", you need to provide a boolean (or a value coercible to a boolean). In a "switch" you don't provide the boolean, but under the hood the switch is just iterating through and comparing your value to all cases: it computes the boolean for you by testing if two values are equal.

Finding a "match" is different, because you're not comparing values, you're also comparing structure. So for example you can do things like

match (v) { case { x, y: 3 } => ... case { y: 3, contents: { name: 'Foo', error }} => ... case { x, y } => ... }

And it wont just compare "v" against all cases, do a deep comparison, check the existance of certain keys and bind variables as necessary so you can use them on `...`.

b. More so than "returning a value" I like to think of it as "resolves to a value". Thinking of it as "returning" can be confusing since it might make it sound too much like a function.

Switch/if are statements. They control flow, and ask the computer to do something. Another statement is assignment; `var a = 0;` "does" something, but it doesn't represent a value.

Expressions like `3 + 2 + x`, `f(x)/2`, and `match({x:3}) {...}` represent a value that hasn't been computed, and then resolve to one.

c. This is why I prefer to think of it as an expression: cause expressions resolve to values. Function calls are expressions too!

d. If you're in a function, all expressions support recursion since you can mix them up. A

e. Awesome.

f. I think that's on purpose, because in a way each case acts a bit like a funciton. You can define "arguments" in it that get bound to values, and they resolve to another value.

Changing `case` in JS to these entirely different semantics would break pretty much everything, which is likely why a new keyword was needed.

It would also remove the duplicity in the first example shown where match(res) matches on the statusCode field (I guess because `200` is declared as a literal ? while the variable is extracted out. Which also means you cannot match against variable content.

It would also retain a level of readability while the proposed syntax has no readability for the uninitiated. Doing that too much makes the language harder to read and learn for beginners.

My basic stance is that a language does not have to be perfectly concise but a good compromise between readability first and density second.

It is always nice to optimize a language for experts but the majority of users of a language such as javascript are not veterans.

You seem to have quite strong opinions with regards to what's good and what's bad considering you don't have enough experience to recognize language features which have existed for decades outside the JS environment.

Given current speed of iteration I think you can cut that in half. The key will be implementations - Babel plugins help with that.

  return match(user, [
          [{first: $, middle: $, last: $}, (f, m, l) => f + ' ' + m + ' ' + l],
          [{first: $, last: $}           , (f, l) => f + ' ' + l],
          [_, 'unknown']
      ]);

Example:

    // simple factorial
    const factorial = n => match(n)
        .when(0, 1)
        .otherwise(n => n * factorial(n - 1));

    // walking a tree
    class Tree {
        constructor(left, right) {
                this.left = left;
                this.right = right;
        }
    }

    class Node {
        constructor(value) {
                this.value = value;
        }
    }

    const T = (l, r) => new Tree(l, r);
    const N = v => new Node(v);

    const walkT = t => match(t)
        .when(Node, v => console.log(v.value))
        .when(Tree, t => { walkT(t.left); walkT(t.right)})
        .otherwise(_ => 'error');

    const mapT = (f, t) => match(t)
        .when(Node, v => N(f(v.value)))
        .when(Tree, t => T(mapT(f, t.left), mapT(f, t.right)))
        .otherwise(_ => { throw new Error('error') });

[1] https://github.com/MarkusPfundstein/pmatch-js

This is basically what they could translate into without having if/else or nested ternaries.

I'm not sure if it is much better than either but I like it more.

Babel supports it if you want to live on the bleeding edge: https://babeljs.io/docs/plugins/transform-do-expressions/

It would be kind of neat if JSX implicitly used "do" expressions in children expressions, though the ternary operator is already very useful in JSX, and more concise [1]

1. https://prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEBhCB...

Not to mention the if/else expression, a ? b : c

Then you HAVE TO HAVE types, otherwise reasoning about effects in these constructed statements would break your mental spine.

Blasphemy.

At least for me, I feel I'd be using this a lot for the boring but common use case of checking for empty arrays and such:

  const doSomethingToArr = arr => match (arr) {
    [] => whatever,
    [x] => whatever,
    [x, ...xs] => whatever
  }

And it isn't four lines saved, but four lines times the number of uses in the entire code base.

What I've seen doing fairly fast and loose prototyping and product iteration in Elixir over the last 2 years, is that patten matching can help create better boundaries and data guarantees within a codebase. A bug might still cause a runtime exception, but investigating and fixing the bug can be wayyyyy less painful than in JS, Ruby and friends when a nill/null/undefined/some-other-garbage can be passed very far through the stack before it eventually causes an issue.

Having a pattern match in the code, even a weak, non-typed pattern match on literals or basic data types, can act as an assertion in your code. "This is what the data needs to look like here if anything after is going to work". I think there is a probably an antipattern in taking this too far, coupling all sorts of your codebase to lower-level data structures There are better controls and safety mechanisms that can be implemented, but it can help a lot when there are specific parts of a codebase that are hotspots for issues, or where you're just trying to isolate where a data inconsistency is originating.

Exhaustiveness checking is what elevates pattern matching to the other side of the expression problem, which is about getting feedback from the compiler to help you write programs.

Permissiveness is good for small projects but it can feel like getting into a suit tailored specifically for everyone else as projects get bigger.

The benefit is that your polyfill/conversion to something browsers support today is handled by someone else, and your actual code base can point a reader to the proposal to at least make some sense later on.

Not that I imagine many people would encourage using a stage 0 proposal, but it's probably a bit better than everyone writing their own adhoc implementation.

It's the object/class additions where I think it's all going a bit C++.

Start with prototypical inheritance, but with a Java-style `new` keyword that makes everything confusing. Next bolt on classes on the one hand, while correcting your prototype system `Object.create` on the other.

R has 3 different object systems and none of them are any good. How long before JavaScript catches up?

We have different ways of doing the same thing, and you have to know the "right" and "wrong" ways based on whatever was the latest proposal.

We have fringe proposals that are just based on something cool some other language did, and they might stick or they might not.

We'll soon have the really obscure constructs that nobody uses except for this guy on the 3rd floor, and he's really vocal about it so watch out.

Maybe we'll even finally get macros in JavaScript [1] soon.

1: http://peter.michaux.ca/articles/macros-in-javascript-please

https://doc.rust-lang.org/stable/book/second-edition/ch06-02...

1. https://github.com/tc39/proposal-pattern-matching#motivating...

I think the HTTP response is a great example. It can have many status codes which can determine how you want to proceed with that response. If you've worked with handling HTTP responses, you've most likely implemented some version of a 'match' operation before.

As another commenter said, it's like conditionals on steroids.

So this:

  function getStatus(status) {
    if (status === 200){
      return "Success";
    } else if (status === 401){
      return "Fail!";
    }
  }

  var myString = getStatus(response.status);

  var myString = match (status) {
    {200} => "Success",
    {401} => "Fail!"
  }

```

    switch(foo)
    {
       case TextBox t:
          Console.Writeline(t.Text);
          break;
       case TextBox when t.Text = "Bob":
          Console.WriteLine("Hello Bob");
          break;
       case Combobox c:
          Console.WriteLine($"{c.SelectedItem}");
          break;
       case null:
          Console.WriteLine("Ooops, null!");
          break;
       case int i when i == 5:
          Console.WriteLine("got an int, and it was 5!");
          break;
       case default:
           // handle the default case.
           break;
     }

IN languages like F#, pattern matching can compile time check you have covered all bases as well.

e.g, this won't build

````

    type VariableResult =
      | E of string
      | V of string

    let result = V "variable"

    match result with
      | E e -> printf "was error"

As i haven't told it how to handle the V case for that discriminated union. So you get nice compile time checking.

Ugh, how do you format code?

Basically, it's just a proposition for the moment, there's no telling if that's gonna be in the language or not. It's only at stage 2 that it is likely that the feature will be added in the language.

The TC39 process: https://tc39.github.io/process-document/

In terms of chances of standardization, that's a step up from "Hey, I have a great idea", buy there are plenty of Stage 0 proposals that go nowhere because they lose steam.

I think the metric they look for is who is using the Babel plugin for it. If people are doing that, then they it has a better shot of progressing.

Stage 4 is the "this is getting standardized next time" stage

So instead of match (x) { expr... } you would have something like match(x, [ fn... ]) or match(x) { name: fn, name2: fn2 } where fn is like (objectToMatch) => { expr }

    const var =
      val == 1 ? 1 :
      va1 == 2 ? 2 :
      null;