4 ms·

Do you have thoughts on C# 8's increased pattern matching features?

bunderbunder 8y ago
I haven't actually used C#, or any .NET language, since before 7 came out. Based on what I've seen as a sideline observer, though, it looks to me like C#'s pattern matching and destructuring are just syntacitc sugar, and therefore still significantly weaker than what F# has. I don't think you can get to the level of type safety that F#'s pattern matching provides without F#-style algebraic data types. The reason is that a set of algebraic types in F# is effectively bundle of types that are collectively sealed. In C#, you can really only seal the terminal classes in a cluster of types, which means that anyone else can come along and add a new class to the type at a later date, after the initial module is compiled, possibly even at run time. That undercuts your ability to ensure that a branching statement is airtight. I believe C# also still lacks active patterns, which are a pretty killer feature if you're looking to do data-oriented programming.
- victorNicollet 8y ago
  C# now has active patterns (which feel like the `is` pattern matching) in the ability to declare a variable as you pass it as an out parameter to an extension function, e.g. if (num.IsNotPrime(out var a, out var b)) WriteLine($"{num} = {a} × {b}");
platz 8y ago
any kind of pattern matching without the ability to check for exhaustiveness defeats the safety they provide, which is need to make that comparable in utility and power to inheritance (i.e. so you can actually replace inheritance w/ pattern matching.) Much like how the compiler assists you when writing subclasseses so that you've implemented all the required methods, real Pattern Matching (F#) gives you the same guarantees from the compiler that you've handled all the possible cases appropriately. Exhaustiveness checking is what elevates pattern matching to the other side of the expression problem, which is about getting feedback from the compiler to help you write programs. a glorified switch statement does not help you do that, and so you still have to write subclasses to get compiler feedback.
- bonesss 8y ago
  > pattern matching without the ability to check for exhaustiveness defeats the safety they provide This holds for a lot of C# vs F# issues... There is a fundamental difference between "it's valid, but our tooling hides it from us" and "the execution environment guarantees that it can never happen". The single pass compiler, functional foundation, currying syntax, and other features that provide guarantees simply can't be replaced with equally robust syntactical sugar. Much in the same way that writing imperative programs that follow OOP principles in possible, but will never give you the system level guarantees that a compiled class sytem will.
  - kod 8y ago
    Why is the compiler being single pass related to correctness?
    - bunderbunder 8y ago
      I'm guessing that's a reference to how, in an F# project, files have a specific order in which they're compiled, and you can only refer to things that are declared previously in the current file, or in a previous file. It makes accidentally creating circular dependency graphs, which can be a source of technical debt, difficult to do. There is still a facility for introducing mutual recursion, but you have to do it explicitly.

I haven't actually used C#, or any .NET language, since before 7 came out. Based on what I've seen as a sideline observer, though, it looks to me like C#'s pattern matching and destructuring are just syntacitc sugar, and therefore still significantly weaker than what F# has. I don't think you can get to the level of type safety that F#'s pattern matching provides without F#-style algebraic data types. The reason is that a set of algebraic types in F# is effectively bundle of types that are collectively sealed. In C#, you can really only seal the terminal classes in a cluster of types, which means that anyone else can come along and add a new class to the type at a later date, after the initial module is compiled, possibly even at run time. That undercuts your ability to ensure that a branching statement is airtight. I believe C# also still lacks active patterns, which are a pretty killer feature if you're looking to do data-oriented programming.

victorNicollet 8y ago
C# now has active patterns (which feel like the `is` pattern matching) in the ability to declare a variable as you pass it as an out parameter to an extension function, e.g. if (num.IsNotPrime(out var a, out var b)) WriteLine($"{num} = {a} × {b}");

platz 8y ago

any kind of pattern matching without the ability to check for exhaustiveness defeats the safety they provide, which is need to make that comparable in utility and power to inheritance (i.e. so you can actually replace inheritance w/ pattern matching.) Much like how the compiler assists you when writing subclasseses so that you've implemented all the required methods, real Pattern Matching (F#) gives you the same guarantees from the compiler that you've handled all the possible cases appropriately. Exhaustiveness checking is what elevates pattern matching to the other side of the expression problem, which is about getting feedback from the compiler to help you write programs. a glorified switch statement does not help you do that, and so you still have to write subclasses to get compiler feedback.

bonesss 8y ago
> pattern matching without the ability to check for exhaustiveness defeats the safety they provide This holds for a lot of C# vs F# issues... There is a fundamental difference between "it's valid, but our tooling hides it from us" and "the execution environment guarantees that it can never happen". The single pass compiler, functional foundation, currying syntax, and other features that provide guarantees simply can't be replaced with equally robust syntactical sugar. Much in the same way that writing imperative programs that follow OOP principles in possible, but will never give you the system level guarantees that a compiled class sytem will.
- kod 8y ago
  Why is the compiler being single pass related to correctness?
  - bunderbunder 8y ago
    I'm guessing that's a reference to how, in an F# project, files have a specific order in which they're compiled, and you can only refer to things that are declared previously in the current file, or in a previous file. It makes accidentally creating circular dependency graphs, which can be a source of technical debt, difficult to do. There is still a facility for introducing mutual recursion, but you have to do it explicitly.