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

111–120 of 254 posts

Re: JavaScript Pattern Matching Proposal

#111

Post by sloanesturz »

c0nfused wrote: post #93
cshepp wrote: post #35

Pattern matching would be a great addition to JS. I built a pattern matching library[1] with a very similar syntax back in 2015 (although I will be the first to admit that it's a naive implementation). It makes validating/traversing deeply-nested objects much less verbose. I'm excited to see where this proposal goes. [1] https://github.com/cshepp/Kasai

I rather like your syntax compared to the proposed version. It is less concise but must more consistent and parsable: return match(user, [ [{first: $, middle: $, last: $}, (f, m, l) => f + ' ' + m + ' ' + l], [{first: $, last: $} , (f, l) => f + ' ' + l], [_, 'unknown'] ]);

I think that this is not always guaranteed to work, because {first: $, middle: $, last: $} is the same as {first: $, last: $, middle: $}

... so calling Object.keys() is not necessarily going to use a consistent ordering. I think that is why they have to use the more verbose syntax in the other library.

I think you could do something like: {first: $.0, middle: $.1, last: $.2}, (f, m, l) => ... pretty easily, though.

Re: JavaScript Pattern Matching Proposal

#112

Post by WaxProlix »

lgessler wrote: post #108

Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.

And the next person to maintain your codebase would be grateful for your choice and insight, I'm sure.

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

Re: JavaScript Pattern Matching Proposal

#113

Post by pjmlp »

goatlover wrote: post #101
devmunchies wrote: post #92

are there any 10+ year old languages that are "advancing" as quickly as JS? Ruby? Python? C++? Why Not?

You mean are there any other languages trying to quickly catch up to C++'s complexity?

All professional languages reach C++'s complexity, which probably is not as complex as PL/I or Algol 68W were for their time.

Python is my favourite example to pick up on this.

Target at beginners and deemed as simple, yet I doubt anyone is able to know Python semantics since version 1.0 and by looking at a random codebase is able to state what is the minimum Python version required to run the code without errors.

Also I very much doubt anyone knows Python's library cover to cover.

Languages get complex because real world has complex needs.

Even Go, the new poster child of simplicity, now has quite a few warts, because not everyone doing software like Google.

Re: JavaScript Pattern Matching Proposal

#114

Post by goatlover »

pjmlp wrote: post #113
goatlover wrote: post #101

Earlier quoted context omitted.

You mean are there any other languages trying to quickly catch up to C++'s complexity?

All professional languages reach C++'s complexity, which probably is not as complex as PL/I or Algol 68W were for their time. Python is my favourite example to pick up on this. Target at beginners and deemed as simple, yet I doubt anyone is able to know Python semantics since version 1.0 and by looking at a random codebase is able to state what is the minimum Python version required to run the code without errors. Al…

Fair enough, and Python is a good example, but I'm guessing Scheme and Smalltalk managed to stay relatively simple over time, although I don't know how much of that would be chalked up to lack of mainstream support.

Re: JavaScript Pattern Matching Proposal

#115

Post by lgessler »

WaxProlix wrote: post #112
lgessler wrote: post #108

Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.

And the next person to maintain your codebase would be grateful for your choice and insight, I'm sure. Permissiveness is good for small projects but it can feel like getting into a suit tailored specifically for everyone else as projects get bigger.

I did say if. Macros often aren't the right choice, but there are times when they're appropriate, and on the premise that the new syntax would be good and responsible, it's great to not have the headache of monitoring compatibility tables for 2+ years.

When you get to the scale of enterprise software, though, I'd agree with you that the best thing to do is probably not to allow any macros at all. The inevitable abuse at the hands of inexperienced developers would quickly overtake any gains from more responsible macros without perhaps some clever and/or toilsome code review processes.

Re: JavaScript Pattern Matching Proposal

#116

Post by timhwang21 »

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…

I wouldn't necessarily say it's deep equality, it's just a less verbose way of sequentially checking properties. It's not going to check every property.

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
  }

Re: JavaScript Pattern Matching Proposal

#117

Post by serpix »

lgessler wrote: post #108

Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.

some-> (threading macro) and the fact that you can put an s-expression _anywhere_, these two language fundamental features alone put lisps way above c-style languages. You can laugh and continue sipping your espresso while reading the JS community bicker about syntax changes and what you are allowed to type.

Re: JavaScript Pattern Matching Proposal

#118

Post by timhwang21 »

genezeta wrote: post #77

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.

Stage zero proposals generally read less formally. IIRC they are held to lower standards and expected to be formalized in the later stages.

Re: JavaScript Pattern Matching Proposal

#119

Post by Tloewald »

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 provide a replacement for switch, with a name that isn't confusing that doesn't require break but otherwise has switch semantics, isn't recursive (we have a mechanism for that) and has the matching behavior suggested? Assuming we stick with 'match' it would look like:

foo = match(x) { case {y: 1} : /* result if x.y === 1 */; ... }

Seems far less confusing.

Re: JavaScript Pattern Matching Proposal

#120

Post by austincheney »

genezeta wrote: post #77

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.

Absolutely, agree. The code examples should be vanilla code, which could then be expanded to the preferences of any library/framework.
Post reply on HN