JavaScript Pattern Matching Proposal • Hacker News Board

Re: JavaScript Pattern Matching Proposal

#211

Post by owl57 » Thu, Apr 26, 2018, 1:05 AM UTC

Sharlin wrote: post #199

Tloewald wrote: post #191

Earlier quoted context omitted.

I totally get what it does, even if I hadn't seen it before. What I don't get is (a) the use of the word 'match' (that's unfamiliarity) and (b) the proposed syntax which looks like an absolute mess, something worthy of PHP, and the fact that we end up with something that isn't a function but is recursive. Or something. 'x => x = 1' in Javascript, is an expression that resolves to a function. I do understand the diffe…

Apparently they're overloading the meaning of the => "fat arrow" in the proposed syntax. I agree it's confusing because it's already used with lambdas in case of JS, but many languages with pattern matching do use it (eg. Scala, Rust). Other languages like Haskell and F# use the thin arrow -> instead. Pattern matching can be exhaustive or non-exhaustive . Basically, if a match construct is going to be an expression i…

I believe all these languages, if they use some arrow in lambda syntax (so, except Rust), use the same kind of arrow for pattern matching. It's an obvious syntax choice when lambda arguments also use the same destructuring syntax: why would anyone want to remember which of those is `[x,y]->x+y` and which is `[x,y]=>x+y`?

Re: JavaScript Pattern Matching Proposal

#212

Post by always_good » Thu, Apr 26, 2018, 3:07 AM UTC

XR0CSWV3h3kZWg wrote: post #200

heretoo wrote: post #175

Earlier quoted context omitted.

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.

> we believe that the number of bugs is proportional to the number of lines of code Why would you believe that? And if you do believe that why don't you use a code golfing language?

What exactly are you contributing by taking what they said to the extreme?

Should someone now have to point out to you that a million-line function is worse than a ten-line function for calculating fizzbuzz? Is that meaningful discourse in your book?

Re: JavaScript Pattern Matching Proposal

#213

Post by shados » Thu, Apr 26, 2018, 3:10 AM UTC

pjmlp wrote: post #110

habitue wrote: post #16

Earlier quoted context omitted.

This is a Stage 0 proposal. Basically it means somebody with a connection to the TC39 (the committee in charge of the JavaScript standard) has thought this was a good enough idea to put together into a proposal. In terms of chances of standardization, that's a step up from "Hey, I have a great idea", buy there are plenty of Stage 0 proposals that go nowhere because they lose steam. I think the metric they look for is…

Even Stage 4 isn't granted it will end up on the standard, some proposals have died on Stage 4.

Any example? Since stage 3 is roughly "request for implementers", and Stage 4 requires 2 real world implementations and essentially mean "will be part of the standard in the next wave".

The closest thing I can think of is ES6 modules, because the module loader spec wasn't finished, but the syntax still lived on.

Now, stuff getting kicked down from Stage 3, that has happened.

Re: JavaScript Pattern Matching Proposal

#214

Post by denpaDawn » Thu, Apr 26, 2018, 3:20 AM UTC

simonbw wrote: post #124

sloanesturz wrote: post #111

Earlier quoted context omitted.

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.

I believe in es6 Object literals are guaranteed to keep their ordering, and Object.keys() will iterate through them in the order defined.

The ordering of Object.keys() is equal to insertion order of the keys into the object. So if you have an Object generation function, it can insert the keys in the proper order (and take advantage of stuff like v8 hidden classes)

http://2ality.com/2015/10/property-traversal-order-es6.html

Re: JavaScript Pattern Matching Proposal

#215

Post by wtallis » Thu, Apr 26, 2018, 3:43 AM UTC

myrryr wrote: post #202

chc wrote: post #141

Earlier quoted context omitted.

I think you're a super anomalous member of any programming language's community. I doubt even one programmer in a thousand has written F# professionally (not being hipster here — I haven't done it myself).

a LOT of function programmers end up doing a lot of javascript work. I don't think he is odd in any way.

Sure, a lot of functional programmers probably do end up doing javascript work. But that's still a large subset of a very small fraction of programmers in general, and they're definitely still vastly outnumbered by the folks who are barely more than script kiddies.

Re: JavaScript Pattern Matching Proposal

#216

Post by abecedarius » Thu, Apr 26, 2018, 3:59 AM UTC

mattbierner wrote: post #139

I would prefer `match { ... } (value)`, with the `match` keyword essentially creating a function that does the matching when it invoked. Minor seeming change, but then you can think of match as being a generalization of arrow functions instead of a special new language construct (i.e., `(...args) => ...` is just shorthand for `match { ...args => ... }`) I can understand why though they went with similar syntax to a s…

This might be too cute, but you could support both unambiguously: match (subject) { ... } and match { ... }.

Re: JavaScript Pattern Matching Proposal

#217

Post by fro0116 » Thu, Apr 26, 2018, 4:07 AM UTC

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.

Clojure's multimethods covers all of the use cases for pattern matching and then some. I've never felt the urge to reach for pattern matching when writing in Clojure.

Re: JavaScript Pattern Matching Proposal

#218

Post by xodeus » Thu, Apr 26, 2018, 4:35 AM UTC

If I do the following:

  let visFilter = 'foo';
  const newState = match (action) {
    {type: 'set-visibility-filter', filter: visFilter} => console.log(visFilter)
  }

What happens?

Is it checking if action.type === 'set-visibility-filter' && action.filter === 'foo' or is it destructuring the value of action.filter into visFilter?

Re: JavaScript Pattern Matching Proposal

#219

Post by always_good » Thu, Apr 26, 2018, 4:57 AM UTC

xodeus wrote: post #218

If I do the following: let visFilter = 'foo'; const newState = match (action) { {type: 'set-visibility-filter', filter: visFilter} => console.log(visFilter) } What happens? Is it checking if action.type === 'set-visibility-filter' && action.filter === 'foo' or is it destructuring the value of action.filter into visFilter?

Every example in on the readme demonstrates that using an identifier in that position becomes destructured assignment.

Re: JavaScript Pattern Matching Proposal

#220

Post by kbp » Thu, Apr 26, 2018, 5:08 AM UTC

masklinn wrote: post #100

stiGGG wrote: post #69

Earlier quoted context omitted.

Yeah, this applies to all that old Lisp features.

AFAIK pattern-matching is not a historical Lisp feature, it's usually been limited to simple destructuring. In the modern acception of tree patterns (as opposed to text patterns aka regular expressions), I guess it comes from ML (and possibly prolog but prolog's unification goes even further?): it doesn't look like ISWIM had tree patterns and I can't find older references.

> AFAIK pattern-matching is not a historical Lisp feature

Aside from full packages like what lispm mentioned, implementing pattern matching (and later, full Prolog-style unification) in Lisp is a very common exercise in beginner Lisp textbooks, going back decades.