91–100 of 254 posts
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.
Why Not?
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
return match(user, [
[{first: $, middle: $, last: $}, (f, m, l) => f + ' ' + m + ' ' + l],
[{first: $, last: $} , (f, l) => f + ' ' + l],
[_, 'unknown']
]);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.
are there any 10+ year old languages that are "advancing" as quickly as JS? Ruby? Python? C++? Why Not?
Earlier quoted context omitted.
I think there's an argument to be made that switch statements already do something adjacent to pattern matching. At the least, it's close enough that something like: switch(expr) { case 'foo': break; case { foo: bar }: break; } Wouldn't strike me as all that strange. It just shifts the semantics from "are you exactly this" to "do you look like this". For non-object primitives (e.g. string or number), I don't think th…
You'll need to insert a newline and 2 spaces before a code block to be recognized as such: switch(expr) { case 'foo': break; case { foo: bar }: break; } https://news.ycombinator.com/formatdoc
Earlier quoted context omitted.
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.
Aren't decorators also in the works?
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.
Babel supports it if you want to live on the bleeding edge: https://babeljs.io/docs/plugins/transform-do-expressions/
It would be kind of neat if JSX implicitly used "do" expressions in children expressions, though the ternary operator is already very useful in JSX, and more concise [1]
1. https://prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEBhCB...
Earlier quoted context omitted.
> 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.
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.