5 ms·
With traditional matching there are up to five different things: - if x then y else z. This is roughly like a match with a true and false case but it depends o
by dan-robertson 2y ago
With traditional matching there are up to five different things:
- if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is
- match e with { p -> e }. This is the classic pattern match case
- if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ())
- match e with { p when e -> e }. This is matching with a guard but I’ve counted it as a special case because it doesn’t easily designate into a match because of the binding/evaluation order, and the guard is special because it can only go at the top level of the match clause so it isn’t just a special kind of pattern (though maybe it could be)
- let p = e. This is one-case pattern matching used for binding variables or destructuring.
The paper proposes a way to make the first four cases obvious parts of one more unified thing, which makes the language potentially simpler and may reduce some weird warts like where guards can go.
- EPWN3D 2y agoThere's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.
- dan-robertson 2y agoI totally agree that can be the case, but I’m not sure it applies that much to the OP.
- HelloNurse 2y agoSometimes a simple conditional statement grows into something more complex over time and it's nice to keep the same malleable syntax, particularly (as is the case of the article) with good semantic and performance guarantees.
- jerf 2y agoAfter a few years working in Haskell as a hobby, I came to the conclusion that complicated pattern matching is an antipattern. I didn't think of it this way at the time, but my current belief is that complicated pattern matching is an extremely tight coupling to what is being matched, and that's not a good thing. I'm not convinced super powerful pattern matching is even a good idea. I think a lot of the love people have for it is precisely their joy at being about to introduce tight coupling with such syntactical convenience. Syntax affording tight coupling is not a good thing. (Simple pattern matching, especially on branches of a sum type, is fine and useful, especially when you are doing it precisely because the code will need to be changed if the sum type adds or subtracts other branches, and this need comes from something "real" and not merely false coupling. But the deeper in you go with the pattern match the more whatever it is you are reaching in for should be abstracted out into a function.)
- norir 2y agoI agree. I'm generally bearish on any language constructs that are difficult to implement. If it's difficult to implement, that probably means there are subtle edge cases that will manifest in confusing behavior at both runtime and compile time.
- 082349872349872 2y agoInspired by duality, I've been trying to work out a language where there's a more obvious correspondence/symmetry between expressions (which evaluate in an environment of named bindings to produce an anonymous value) and patterns (which destructure an anonymous value to produce an environment of named bindings).
- andyferris 2y agoHave you made any progress?
- 082349872349872 2y agoIn theory, yes: I've used it to derive a (minor but accepted as published) patch to a Turing Award winner's paper; in practice, no. [the semantics haven't changed much over the past years, but the syntax? even as a single person, who ought to be able to come up with a unified design, my different temporal instantiations insist on bike shedding]
- lptk 2y agoAlso check out my other answer here: https://news.ycombinator.com/item?id=41901573 https://news.ycombinator.com/item?id=41901573
- hoosieree 2y agoI like overloading most of the time but prefer specialized syntax for the various conditional idioms. Encapsulating it all in one keyword makes "if" harder to parse.