Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Pattern Matching Proposal

github.com

Post reply on HN
Print view View original

71–80 of 254 posts

Re: JavaScript Pattern Matching Proposal

#71

Post by tannhaeuser »

jerf wrote: post #54
lmm wrote: post #30

Earlier quoted context omitted.

No, not at all. E.g. Erlang is built around pattern matching as a core feature even though it's an untyped language.

Erlang was built from the ground-up with pattern matching in mind, so it works. Instead objects are jammed into the pattern matching system, and where the two disagreed, pattern matching won. (Indeed, Erlang doesn't really even have objects, just some object-like convention.) In a language that started with an object model that has grown a lot of features, trying to jam pattern matching into it after the fact grows a…

I believe Erlang inherited its pattern matching from Prolog term unification since Erlang was prototyped as a DSL using Prolog's op built-in predicate (plus other Prolog parsing DSLs such as definite clause grammars).

[1]: http://www.swi-prolog.org/pldoc/man?predicate=op%2f3

Re: JavaScript Pattern Matching Proposal

#72

Post by gmfawcett »

lpgauth wrote: post #32
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?

No, have a look at Erlang! Pattern matching is one of it's most powerful feature.

And Prolog as well, which strongly influenced Erlang's design. (The original Erlang was written in Prolog.)

I agree with the sentiments of some of the other commenters -- it's much less troublesome to match on tuples (Erlang) and predicate clauses (Prolog) than it is to match on JavaScript objects. With tuples/clauses, the constructor syntax mirrors the pattern matching syntax, so it's trivial to read the code at a purely syntactic level to debug pattern matching issues, and this would simplify automatic static analysis as well. As soon as you can add "fields" to an object at arbitrary (non-local) points in the code, local syntactic analysis becomes intractable.

Re: JavaScript Pattern Matching Proposal

#74

Post by irrational »

c0nfused wrote: post #63

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…

I made the same type of arguments about fat arrows but everyone told me to stop whining and I'd get used to it. Years later fat arrows still feel like a bad syntax choice.

Re: JavaScript Pattern Matching Proposal

#75

Post by kristiandupont »

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.

Why? To me it seems pretty aligned with the "feel" of destructuring.

Re: JavaScript Pattern Matching Proposal

#76

Post by madamelic »

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.

`request.statusCode == 200 && { body: {} } || request.statusCode == 404 && 'Not Found' || throw new Error('Something happened')`

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.

Re: JavaScript Pattern Matching Proposal

#77

Post by genezeta »

Leaving aside syntax preferences or other superficial concerns, I find it discouraging that "Motivating Examples" for a proposal include direct references to particular libraries, or particular libraries' examples.

I mean, that one (of two) motivations for adding a feature to a language is "Terser, more functional handling of Redux reducers", just feels wrong and casual.

Re: JavaScript Pattern Matching Proposal

#78

Post by ealhad »

Dibes wrote: post #61
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.

“looking bad” is a really subjective thing.

Here is the syntax for different languages:

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

- Haskell http://learnyouahaskell.com/syntax-in-functions

- Scala https://docs.scala-lang.org/tour/pattern-matching.html

Re: JavaScript Pattern Matching Proposal

#79

Post by 1ris »

lghh wrote: post #44
1ris wrote: post #40

Earlier quoted context omitted.

That's not how it works. You don't have to be Steven Spielberg to dislike some Hollywood movie. How is this fallacies called?

There's a totally different barrier of entry for that than suggesting a syntax. That's not even in the same stratosphere.

There was a suggestion: Make it like switch/case.

Re: JavaScript Pattern Matching Proposal

#80

Post by bschwindHN »

codedokode wrote: post #58
bschwindHN wrote: post #29

Earlier quoted context omitted.

Let's see an example of your proposed alternative syntax.

Here you are: var x = match (response) { case { status:200 }: true; case { status: 404 }: new NotFoundError; case Number: Math.PI; case SomeClass: 1; case /^http/: "http error"; default: -1; };

I like it, especially `default` instead of `{}`

The leading curly braces in the linked proposal _are_ a bit odd to see, though the repetition of `case` isn't too fun either.

Post reply on HN