3 ms·
> the limits of pattern-matching in languages that do support it And then goes to discuss Rust only. Nope. In many languages pattern matching is crippled beca
by dmitriid 6y ago
> the limits of pattern-matching in languages that do support it
And then goes to discuss Rust only. Nope. In many languages pattern matching is crippled because it is only allowed to be used in some contexts, but not in others. Or are crippled by things like "can't pattern match if something-something pointers".
For example, in Erlang you can use pattern matching and guards in function definitions, creating overloaded functions based on pattern-match alone. And you can match arbitrarily complex structures (because it doesn't have pointers etc.). This makes working with ASTs in such a language a breathe.
- jerome-jh 6y ago> "can't pattern match if something-something pointers" The main confusion I see is that in many languages it is unclear whether sum types are a runtime or compile time thing, which decides whether pattern matching is semantic or syntactic. Of course nobody wonders whether "if then else" is semantic, but for pattern matching I admit I am myself confused: - in C all types are compile time (and loosely enforced) so if you want sum types, do them yourself. Implementing the matching is quite straightforward but unsafe and pedantic. - in Java all type information is available at runtime: sum types can be implemented easily (casting to Object), matching is safe and can be compact if done with e.g. arrays. - in C++ thinks start getting trickier: you can certainly do a lot mixing static and dynamic casts, but will this remain readable? - in ML languages: AFAIK this is completely implementation defined. The compiler may choose to box some or all variables. Obviously in such a language you much less care about what is going on under the hood. In return you get a true pattern-matching construct. - in Rust and others: frankly I don't know where they stand in regard of compile time vs runtime :)