Proposal-pattern-matching: match { } without parameter

[azz]

I feel like 90% of use cases of match will be like this example from the README:

let isVerbose = config => match (config) {
    { output: { verbose: true } }: true,
    else: false
}

Wouldn't it make sense to allow a no-arg version of match that effectively returned a function? Thus:

let isVerbose = match {
    { output: { verbose: true } }: true,
    else: false
}

This will remove the need to bind a name to config, thus allowing point-free pattern matching.

[keithamus]

Seems like let isVerbose = config => Boolean(config?.output?.verbose) would be just fine as a function without using matches.

[littledan]

Maybe this could be an extension of the partial application proposal, e.g.,

match ? {
    { output: { verbose: true } }: true,
    else: false
}

cc @rbuckton

[azz]

I imagine there will be grammar issues there. Maybe match (?) { ... }

Interesting note, if the (param) syntax is completely dropped, it could be added to the end like a function call.

const configIsVerbose = match {
    { output: { verbose: true } }: true,
    else: false
} (config);

This would be (roughly) like the following do-expression:

const configIsVerbose = do {
    ({ output: { verbose } }) => verbose === true
} (config);

[csreid]

I feel like 90% of use cases of match will be like this example from the README

I disagree with that.

[azz]

Maybe I was too broad, what I am suggesting is that

identifier => match (identifier)

will be highly common.

[freddi301]

These syntax sugars could enable a ML like pattern matching or at least a erlang-one like.
(don't know if following examples has syntax clashes)

const isVerbose = match {
    { output: { verbose: true } }: true,
    else: false
}

function overloadedOne(...args) {
  return match (args) {
    [{ half }]: half / 2,
    [{ double }]: double * 2,
  };
}
// syntax sugar
function overloadedOne {
  [{ half }]: half / 2,
  [{ double }]: double * 2,
}

class A {
  foo {
    [{ bar }]: this,
    [{ baz }]: do { this.y += "bump"; this; }
  }
}

[baptistemanson]

Hi all,

Syntactic sugar without the match keyword
@freddi301 I made two versions of the overloadedOne function:

const overloadedOne = () => {
  "a": 1,
  "b" 2,
}

is pretty close to:

const overloadedOne = () => ({
  "a": 1,
  "b" 2,
})

Will we make our life easier with this syntactic sugar? It becomes hard to catch the difference don't you think?

Syntactic sugar for no-arg version
@azz we are lucky because there is a track record of usage of pattern matching in other languages, such as OCaml or Haskell.
So I read the codebase of Reason:
Out of the 45 occurrences of match, I could find only 1 straight "function x => match (x)". So 2%.
Match:

• is used on an attribute of the input:

const testFunction = x => match(x.attr) {},

• inlined in a larger function when only used once:

const testFunction = x => { 
   const y = match(x){
   }
},

• applied directly on the result of a function:

 x => match(pop(x)) {}

• used in a function taking two parameters

 (x,y) => match(x) { }

We may use it differently in JS. If someone else could consolidate a few other datapoints from other codebase, that would be fantastic.

My opinion for now: By reading existing codebases using pattern matching, it seems that the no-arg version will be rare and/or unknown by many. No-arg version may raise confusion.

[littledan]

I share the confusion concern from this thread.

[freddi301]

@baptistemanson 2% of match in Reason codebase is not a significative research.

1. OCaml relies way less on pattern mathcing than Haskell for example
2. what about the top level pattern matching all over the place?

[baptistemanson]

@freddi301 Do you suggest studying Haskell usage would be more relevant than Ocaml usage for determining what we should bring to Js? I believe you. I don't know Haskell; it may be obvious for those like you who have knowledge of both languages.

I started reading the codebase of GHC, which sounded like a good codebase. To detect usage in Haskell of the proposed syntax, I should be looking for:

• functions with a body that is only doing one pattern matching operation, being a guard, pattern match or a case,
• with only one parameter in,
• not using "where".
  Right?

[baptistemanson]

@freddi301 Hmm I may have missed quite a lot of occurrences. Maybe you can help me? I don't know Haskell enough to guarantee result.
I didn't find that many (44 out of 533 I loooked at). It seemed that the trivial case equivalent to x => match(x) end up being inlined where needed and not in an independent function.

[zkat]

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

Note that the new spec _does_ have a "Beyond This Spec" section on the bottom that does cover some of the things this issue intends to address. I still consider it out of scope for this specific proposal, but there's definitely stuff to explore here.