What does HackerNews think of proposal-pattern-matching?
Pattern matching syntax for ECMAScript
https://github.com/tc39/proposal-pipeline-operator - Stage 2
https://github.com/tc39/proposal-pattern-matching - Stage 1
Hopefully we get both in the next couple of years.
I'm not sure if it's stalled or not. But it's being discussed.
We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.
Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)
https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pattern-matching
Pattern matching: https://github.com/tc39/proposal-pattern-matching
Do expression: https://github.com/tc39/proposal-do-expressions
Pipe operator: https://github.com/tc39/proposal-pipeline-operator
The specifics of the proposal will likely shift a bit since it's still stage 1 (2?).
> Related, Typescript is the only language I know of that through flow analysis does not require you to redefine the variable. E.g. you can do something like
This is called smart casting and is widely used in Kotlin
https://github.com/tc39/proposal-pattern-matching
Also there has been movement in the user land space with libraries like ts-pattern that make use of new features in typescript 4.x to provide basically the full pattern matching experience:
There is currently a Stage 1 proposal for a pattern matching syntax presented to TC-39. If it reaches Stage 3 then it is presumed likely Typescript will implement it.
No, I wasn't talking about C; or about language implementations at all. I was arguing that the phrase "just allowing named parameters" gives the impression that this feature would only affect function calls and definitions, when that's not the case. The most obvious repercussions are for `call_user_func`, `func_get_args`, etc. whose API would need to change. That induces changes to code that calls those functions, and code that calls that code, and so on.
Although PHP is famously un(der)specified, I'm talking about things like "`call_user_func(f, args...)` is equivalent to `f(args...)`"; anything relying on that property will break in the presence of named parameters (since they may be given in a different order), unless patched to take it into account.
> Whether I as a function author decide to re-order my arguments is a decision informed but not dictated by the existence of named arguments.
Sure, but that's just a first-order effect. It's a breaking change for higher order code (where functions and arguments are data, and calling is an operation on that data). That's why I gave an example of higher-order code.
As a silly analogy: if PHP extended its default numeric types to be complex numbers, that wouldn't affect existing values like `$age = 18` or `$length = 50`, since they're "informed, but not dictated by the existence of complex numbers"; it also wouldn't affect calculations using these values like `plus($age, $length)`. Yet it would have profound effects on numeric functions, which may have to be patched to take complex values into account: some functions, like `array_sum`, might work fine as-is; whilst others, like `array_slice`, might make no sense given the new situation (how might we take `3+5i` elements from an array?).
> All your "alternative" solutions read like horrible code to me compared to the now commonly accepted designs.
This sentence is a good example of what my "rant" is about. Why should improvements depend on what's "commonly accepted" (surely that's antithetical)? Could you elaborate any further on what makes those examples "read like horrible code"?
As a more detailed example we can look at `switch`: it's clearly a "now commonly accepted design", due to its prevalence in many "popular languages" like PHP/Javascript/etc. An alternative approach which solves the same problem is `match`, as used by ML. However, ML is not a popular language, and ML also introduced currying which you say "read[s] like horrible code". Does that make `switch` better than `match`?
This is an interesting example since a recent Python Enhancement Proposal is trying to add `match` to the language. This proposal seems credible, since the author list includes Guido van Rossum (the creator of Python): https://www.python.org/dev/peps/pep-0622
Perhaps this is an outlier, since Python doesn't already have an equivalent like `switch`?
I wonder if the existence of that PEP changes your opinion of `switch` versus `match`? Maybe not; after all, Python doesn't have `switch` so maybe `match` is better than nothing. What if I showed you an equivalent proposal for adding it to Javascript (using the keyword `case`, like the non-popular language Haskell)? https://github.com/tc39/proposal-pattern-matching
At what point does a feature go from "horrible code" to "stealing each others' best ideas"?
What makes this even more interesting is that the very first sentence of PEP622 makes it clear that this is a case of stealing a good idea:
> This PEP proposes to add a pattern matching statement to Python, inspired by similar syntax found in Scala and many other languages.
To add a further wrinkle, PEP3103 was rejected for proposing essentially the same idea back in 2006: https://www.python.org/dev/peps/pep-3103/
Perhaps it was too soon to adopt ideas from Scala, since it had only been out for a couple of years by that point. However, `match` wasn't invented by Scala; it's been around in multiple languages, some more popular than others, dating back to 1973!
As further evidence of this, there was another rejected PEP for the same basic idea, from way back in 2001: https://www.python.org/dev/peps/pep-0275
I wonder whether your line of reasoning would come out in in favour of PEP622 today, whether it would have come out in favour of PEP275 twenty years ago, and whether it will argue in favour of `match` twenty years from now?
Rust’s pattern matching is deliberately fairly limited in what it can do; it’s all about destructuring types, not running arbitrary code like Perl’s smart-match (which even so I would not describe as a disaster). It’s conceptually very clean—arguably simpler than what ECMAScript already has. `let PATTERN = EXPRESSION;`, `if let PATTERN { … }`, `match EXPRESSION { PATTERN => … }`, `fn NAME(PATTERN: TYPE)`, &c., everything that can introduce a new binding is a pattern. Some of the uses of patterns are refutable (match branches, `if let`, `while let`), and some irrefutable (`let`, `for`, function arguments, closure arguments).
ECMAScript already has destructuring in various places, corresponding to irrefutable pattern matching; what the proposal’s `case` expression introduces is essentially just refutable destructuring, plus a smidgeon of expression-orientation (`->` corresponding to `=>`, that `case` is an expression that yields a value, rather than a statement) in a place that sorely needs it. This is a very logical extension of the language.
If TC39 or equivalent were to design a new language to actively replace JavaScript (meaning something that all extant JavaScript code should be able to migrate to easily, preferably automatedly), there is no doubt in my mind that the language would be more expression-oriented than ECMAScript is, that destructuring syntax would be brought in line with what we call pattern matching so that there was one coherent concept underneath (probably called pattern matching), and that `switch` would use it, becoming equivalent to this proposal.
The way people use JavaScript these days, these things are useful.
(I write all this as an expert and heavy user of both Rust and JavaScript; I use JavaScript more, most of the time, but prefer Rust. Rust was the first language I learned with each of algebraic data types, pattern matching and expression orientation.)
One of the greatest powers of pattern matching comes from being abole to match in function definitions. The simplest example:
fac(0) -> 1;
fac(N) when N > 0 -> N*fac(N-1).
[1] https://github.com/tc39/proposal-pattern-matching
[2] http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.h...
``` def handle(%{state: "open", balance: balance},%Deposit{amount: amount}) do {:ok, %{state: "open", balance: (balance + amount)}} end
def handle(%{state: "closed"}, %Deposit{}) do {:error, "invalid action: account closed"} end
```
Every state/event pairing is explicitly defined as a variation of the `handle` method. There are countless ways to build a state machine like this, but the basic pattern matching primitive seems to simplify this a lot.
An extension to javascript to support this has been proposed, I'm hopeful that it gets considered seriously: https://github.com/tc39/proposal-pattern-matching