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

231–240 of 254 posts

Re: JavaScript Pattern Matching Proposal

#231

Post by abritinthebay »

bterlson wrote: post #172
abritinthebay wrote: post #171

Earlier quoted context omitted.

> if it clears TC39 (a tall order, to be honest), won't land in a spec for half a decade at least I would bet. Given current speed of iteration I think you can cut that in half. The key will be implementations - Babel plugins help with that.

The current speed of iteration means you get updates in smaller batches rather than more throughput. Still important, but it's not like we're letting proposals bake less. Note how so far we've only gotten two big new features post-ES6 - async functions and async generators. Further, some features (e.g. decorators, bind operator) have had babel plugins for years and yet hasn't shipped in a spec.

True. Mostly due to hold ups in the Stage 3 — Stage 4 process I think

Re: JavaScript Pattern Matching Proposal

#232

Post by fauigerzigerk »

This reads very much like an ideology first, evidence second piece.

How on earth is it bizarre to make neighborhood roads worse to drive on for commuter traffic? And defunding public transport?

You can have a debate about these things, but calling it bizarre betrays the sort of "reasoning" that is dominated by an ideological anti public-anything bias.

Re: JavaScript Pattern Matching Proposal

#233

Post by thesz »

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.

Then you would like to have statements as first class objects (e.g., to build them and pass around) and you are one step away from monads of Haskell.

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

Blasphemy.

Re: JavaScript Pattern Matching Proposal

#234

Post by mgoetzke »

Tloewald wrote: post #119

So the proposal is super confusing to me (but I hadn't seen match before). At first I thought it had something to do with regex. Essentially it's a switch variant that is (a) confusingly named 'match' (bad) (b) returns a value (good?) (c) and is actually a kind of function (wha?), since it (d) supports recursion, but (e) doesn't require break (good), (f) looks like a bag of inline functions but isn't (bad). How about…

a match(x) {...} to augment switch(x) { ... } would be very welcome indeed. It would also get rid of the function scopes which imply actual function objects/closures which are not actually 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.

Re: JavaScript Pattern Matching Proposal

#235

Post by rootlocus »

Tloewald wrote: post #119

So the proposal is super confusing to me (but I hadn't seen match before). At first I thought it had something to do with regex. Essentially it's a switch variant that is (a) confusingly named 'match' (bad) (b) returns a value (good?) (c) and is actually a kind of function (wha?), since it (d) supports recursion, but (e) doesn't require break (good), (f) looks like a bag of inline functions but isn't (bad). How about…

> Essentially it's a switch variant that is (a) confusingly named 'match' (bad)

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.

Re: JavaScript Pattern Matching Proposal

#236

Post by mgoetzke »

heretoo wrote: post #175
bastawhiz wrote: post #46

I can only see this being a foot gun. Deep equality testing of objects is going to encourage the use of getters. Getters with side effects (no way to prevent them) will basically ruin your day if you try to use pattern matching with them. Additionally, this would be the first "native" way to do deep equality testing of objects. I can see it being abused to do simple one-off checks that could otherwise have been done…

If it is five lines of code vs. one line of code, and we believe that the number of bugs is proportional to the number of lines of code, irrespective of which language we are programming in, then this would be an obvious benefit. And it isn't four lines saved, but four lines times the number of uses in the entire code base.

I would agree, BUT code needs to be readable first. The proposed syntax applied to e.g switch would have just braces which would not look very readable.

Having less lines can make extremely unreadable code. Readable code with an error is easy to fix, unreadable code is not.

At the very least the ambiguity of doing TWO things (matching AND destructuring) should not be allowed since it changes the outcome based on whether a value is a literal or a variable with the exact same literal assigned to it (at least that's how I understand it from reading the examples)

Re: JavaScript Pattern Matching Proposal

#238

Post by masklinn »

edflsafoiewq wrote: post #161
masklinn wrote: post #107

Earlier quoted context omitted.

C's switch/case is essentially a special case with a limited set of values (literals) and no destructuring. You can extend it to less trivial patterns and blam pattern matching.

No, switch is not like a special case of match. C's switch is a kind of computed goto and can build irreducible control flow graphs. match is a reducible structured control-flow construct whose power comes from destructuring. match is much, much more like an if-else chain than a switch.

> No, switch is not like a special case of match.

Sure is. Or a degenerate one if you prefer.

> match is a reducible structured control-flow construct whose power comes from destructuring.

Match on sum types with no associated data and you have a switch.

> match is much, much more like an if-else chain than a switch.

Depends on what you're matching.

Re: JavaScript Pattern Matching Proposal

#239

Post by Can_Not »

christophilus wrote: post #125
curun1r wrote: post #121

Earlier quoted context omitted.

It's probably more of a "know your audience" decision. Anyone who's used an ML-derived language will understand the motivation for pattern matching. But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory, so they chose an example that's likely to resonate more with that group.

> But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory Not to side-track the issue, but I keep hearing this. I'm wondering if this is true, and if so, how such a statement is verified. I'm currently a full-time JS dev, but have written my own programming languages, have professionally written in C, C++, C#, F#, Ruby, and others, and have…

I'm s full time JS dev too. People keep saying that JS sucks or whatever, but [Rust, Clojure, OCaml, Haskell, PureScript, Erlang, Elixir, Elm, Scala, Nim] jobs are just so rare that picking one and going deep is basically like hoping to win a lottery.

Re: JavaScript Pattern Matching Proposal

#240

Post by edflsafoiewq »

masklinn wrote: post #238
edflsafoiewq wrote: post #161

Earlier quoted context omitted.

No, switch is not like a special case of match. C's switch is a kind of computed goto and can build irreducible control flow graphs. match is a reducible structured control-flow construct whose power comes from destructuring. match is much, much more like an if-else chain than a switch.

> No, switch is not like a special case of match. Sure is. Or a degenerate one if you prefer. > match is a reducible structured control-flow construct whose power comes from destructuring. Match on sum types with no associated data and you have a switch. > match is much, much more like an if-else chain than a switch. Depends on what you're matching.

No it isn't. Again, switch can build irreducible control flow, match cannot. This code

    switch (x) {
    case 0:
        while (i
cannot be rewritten with a simple match. You'd have to reloop the CFG.
Post reply on HN