JavaScript Pattern Matching Proposal • Hacker News Board

Re: JavaScript Pattern Matching Proposal

#61

Post by Dibes » Wed, Apr 25, 2018, 3:59 PM UTC

d--b wrote: post #24

Javascript is such a mess, this proposal looks really bad, and the guys discussing it are saying things like: "we should make sure that this doesn't look like anything else, so that people who learn the language don't confuse match and switch..." There is also a lot of "we shouldn't break that" messages, and people reply with "oh we already screwed that up here and there, so it's fine"...

as someone who only has a little experience with pattern matching, how does this look bad? The syntax looks good enough to me that I could and would want to use it.

Re: JavaScript Pattern Matching Proposal

#62

Post by Epenthesis » Wed, Apr 25, 2018, 4:01 PM UTC

z3t4 wrote: post #41

Stop using (nested) ternary operator's ! Use if-statements! if(val==1) var res = 1; if(val==2) var res = 2;

Except ternary expressions have the huge advantage that they allow assigning to const. Eg:

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

Re: JavaScript Pattern Matching Proposal

#63

Post by c0nfused » Wed, Apr 25, 2018, 4:01 PM UTC

Its an interesting concept but, The choice of syntax seems bad.

The definition bit looks like a function definition but behaves entirely differently. Why? Why not make it a constructor like everything else? People could look at it and be like "oh a match object" instead of wondering if you overloaded function.

The selectors look like json, only assignable. Again make it obvious.I mean we could even just make it json why not.

Re: JavaScript Pattern Matching Proposal

#64

Post by platz » Wed, Apr 25, 2018, 4:02 PM UTC

lolive wrote: post #23

Isn't pattern matching interesting only in a strongly typed environment where the compiler can statically check that you are giving instructions for all possible cases?

That is why I think we need some way to identify pattern matching + exhaustiveness checking, vs non-exhaustive switching matching is really more like "destructuring with syntactic sugar".

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.

Re: JavaScript Pattern Matching Proposal

#65

Post by ryanmarsh » Wed, Apr 25, 2018, 4:02 PM UTC

d--b wrote: post #24

Javascript is such a mess, this proposal looks really bad, and the guys discussing it are saying things like: "we should make sure that this doesn't look like anything else, so that people who learn the language don't confuse match and switch..." There is also a lot of "we shouldn't break that" messages, and people reply with "oh we already screwed that up here and there, so it's fine"...

I don't understand what all the fuss is about. Just looking at the syntax examples given, it looks really nice and I would jump at the opportunity to use it.

Re: JavaScript Pattern Matching Proposal

#66

Post by dtech » Wed, Apr 25, 2018, 4:02 PM UTC

sakuronto wrote: post #34

Interestingly, the match construct is an expression, which I don't think JavaScript has m/any of. Perhaps they could retroactively make if/else expressions, if that doesn't break back-compat.

Javascript already has a conditional expression, the ternary operator: `condition ? expr-if-true : expr-if-false`.

Re: JavaScript Pattern Matching Proposal

#67

Post by disconcision » Wed, Apr 25, 2018, 4:03 PM UTC

lolive wrote: post #23

Isn't pattern matching interesting only in a strongly typed environment where the compiler can statically check that you are giving instructions for all possible cases?

As well as erlang, see also racket/match, perhaps the most comprehensive implementation of pattern-matching anywhere: https://docs.racket-lang.org/reference/match.html

Re: JavaScript Pattern Matching Proposal

#68

Post by c0nfused » Wed, Apr 25, 2018, 4:04 PM UTC

cevn wrote: post #37

sakuronto wrote: post #34

Interestingly, the match construct is an expression, which I don't think JavaScript has m/any of. Perhaps they could retroactively make if/else expressions, if that doesn't break back-compat.

That would be really cool. This match feels a lot like Rust's which is good.

I would argue that it doesn't feel like JavaScript much which seems bad.

Re: JavaScript Pattern Matching Proposal

#69

Post by stiGGG » Wed, Apr 25, 2018, 4:07 PM UTC

lmm wrote: post #38

adamnemecek wrote: post #13

Earlier quoted context omitted.

It's been "trendy" since the 70's. It's more that more people have experience with it and realize that pattern matching is like conditional statements on steroids.

> It's been "trendy" since the 70's. It's been possible since the '70s but I've seen a lot more talking about it in the last 5-10 years.

Yeah, this applies to all that old Lisp features.

Re: JavaScript Pattern Matching Proposal

#70

Post by irrational » Wed, Apr 25, 2018, 4:08 PM UTC

c0nfused wrote: post #68

cevn wrote: post #37

Earlier quoted context omitted.

That would be really cool. This match feels a lot like Rust's which is good.

I would argue that it doesn't feel like JavaScript much which seems bad.

I'd argue they've already started going down the "doesn't feel much like JavaScript" road when they started introducing things like fat arrows. I agree that it is bad.