3 ms·
> I think its because until recently pattern matching and > algebraic data types (a more robust alternative to > switch statements) [...] Could you el
by runeks 10y ago
> I think its because until recently pattern matching and
> algebraic data types (a more robust alternative to
> switch statements) [...]
Could you elaborate a bit on what this accomplishes, eg. pattern matching vs a "case" statement? As I've programmed in Haskell for the past year or two, I've observed exactly this change in my style of writing - that I've started to get rid of "case" statements inside function definitions, and have moved them into the pattern-matching part instead ("outside" the function definition).
But I have to admit, I'm not entirely sure why I do this. It just feels more robust to me in some way.
- sundarurfriend 10y agoJust FYI, I asked a pretty similar question a few months ago here [1]. The main arguments for pattern matching seemed to be that: * [at least some] compilers will check for exhaustiveness * "Pattern matching isn't just conditional matching. It's also binding, and even some common operations. " [1] https://news.ycombinator.com/item?id=11159321 https://news.ycombinator.com/item?id=11159321
- ufo 10y agoI was just comparing the pattern matching from FP languages with the more primitive C-like switch statement. The big advantage comes from the algebraic data types (tagged unions), which let you model data with many "cases" in a type-safe manner. For example, in Haskell we don't have null pointers because we can use the Maybe type instead. The case-expression vs function-definition difference you mentioned from Haskell is just syntactic sugar. In both situations you are doing exactly the same pattern matching under the hood.