4 ms·

Watched a FP demo in Scala last week. As an F# guy, I was curious about the syntax. I probably didn't get it, but what I thought I saw was a bunch of cool FP c

Watched a FP demo in Scala last week. As an F# guy, I was curious about the syntax. I probably didn't get it, but what I thought I saw was a bunch of cool FP concepts bolted on top of a pretty long-in-the-tooth OO language. About the time the guy added the third custom DSL, I decided I would never ever code like that. I like C#. I love OO. And I'm crazy about pattern-matching. But why do we think that combining good things from other places, we always get something that's better? Perhaps we should start defining languages by what they don't do? Otherwise, everything will do everything -- and that increases cognitive load on the developers and leads to lots of noob errors by those just starting out. Could somebody explain to me what we would like to achieve with this?

Locke1689 12y ago
Perhaps you'd like to explain why you think pattern matching has any necessary connection to functional programming? Sure, popularized by ML, but otherwise I'm not buying it. We already have switch and type-checking statements. Those are just special cases of pattern matching.
- kyllo 12y ago
  But do your "switch and type-checking statements" allow you to implement a single polymorphic function and also give you a helpful compiler error when your switch is non-exhaustive?
  - Locke1689 12y ago
    allow you to implement a single polymorphic function What do you mean by this? And which type of polymorphism?
    - hvidgaard 12y ago
      Perhaps he is talking about parametric polymorphism? In any case, having the compiler tell you that your pattern matching is not exhastive, and even demand that it is, prevents a whole class of problems and enable you to expand your program and have the compiler help you if you forget to add some new case in a pattern matching.
    - kyllo 12y ago
      Parametric. In ML-family languages (SML, OCaml, Haskell) you can define a function that pattern-matches its signature. For example (taken from the Wikipedia article on SML) I could define an algebraic datatype "shape" as such: datatype shape = Circle of loc * real (* center and radius *) | Square of loc * real (* upper-left corner and side length; axis-aligned *) | Triangle of loc * loc * loc (* corners *) Then I could define an "area" function that takes this as a parameter and pattern-matches on its type as such, with a different implementation depending on the type: fun area (Circle (_, r)) = 3.14 * r * r | area (Square (_, s)) = s * s | area (Triangle (a, b, c)) = heron (a, b, c) (* call to Heron's formula function *) Which is also syntactic sugar for: fun area shape = case shape of Circle (_, r) => 3.14 * r * r | Square (_, s) => s * s | Triangle (a, b, c) => heron (a, b, c) If I were to implement the function like: fun area shape = case shape of Circle (_, r) => 3.14 * r * r | Square (_, s) => s * s and forget to include the Triangle case, I would get a compiler error: "match nonexhaustive". Furthermore if I were to include a redundant case or an unreachable case, the compiler would also throw an error informing me of that. Very useful in preventing runtime errors, and languages like Java or C/C++ simply do not provide this.
      - Locke1689 12y ago
        Yes, that is how pattern matching works, and no, it has nothing to do with parametric polymorphism. No plans to add extra sugar to immediately switch on the arguments of a function, but I'm pretty sure that switch(arg) is not terrible overhead. I've addressed exhaustivity in a different comment.
_random_ 12y ago
I prefer C# + average pattern matching + first-class IDE support to F# + first-class pattern matching + basic IDE support. C# without pattern matching is not an option :).
dragonwriter 12y ago
> I probably didn't get it, but what I thought I saw was a bunch of cool FP concepts bolted on top of a pretty long-in-the-tooth OO language. Well, yeah, if providing a good transition path for Java developers and a solid Java two-way interop story (including low-cognitive-overhead mapping of Java APIs) wasn't important, Scala would just be Haskell. > Perhaps we should start defining languages by what they don't do? There's plenty of languages that are defined by relatively pure adherence to a particular model and not letting you do things outside of it. Neither Scala nor C# have ever been among them (Java -- for one model of OOP -- and Haskell for pure functional programming are examples, not being that way is one of the things that distinguished C# from Java.) > Could somebody explain to me what we would like to achieve with this? With, what, exactly -- pattern matching in C#? Or the kitchen-sink approach to language features more generally?

Locke1689 12y ago

Perhaps you'd like to explain why you think pattern matching has any necessary connection to functional programming? Sure, popularized by ML, but otherwise I'm not buying it. We already have switch and type-checking statements. Those are just special cases of pattern matching.

kyllo 12y ago
But do your "switch and type-checking statements" allow you to implement a single polymorphic function and also give you a helpful compiler error when your switch is non-exhaustive?
- Locke1689 12y ago
  allow you to implement a single polymorphic function What do you mean by this? And which type of polymorphism?
  - hvidgaard 12y ago
    Perhaps he is talking about parametric polymorphism? In any case, having the compiler tell you that your pattern matching is not exhastive, and even demand that it is, prevents a whole class of problems and enable you to expand your program and have the compiler help you if you forget to add some new case in a pattern matching.
  - kyllo 12y ago
    Parametric. In ML-family languages (SML, OCaml, Haskell) you can define a function that pattern-matches its signature. For example (taken from the Wikipedia article on SML) I could define an algebraic datatype "shape" as such: datatype shape = Circle of loc * real (* center and radius *) | Square of loc * real (* upper-left corner and side length; axis-aligned *) | Triangle of loc * loc * loc (* corners *) Then I could define an "area" function that takes this as a parameter and pattern-matches on its type as such, with a different implementation depending on the type: fun area (Circle (_, r)) = 3.14 * r * r | area (Square (_, s)) = s * s | area (Triangle (a, b, c)) = heron (a, b, c) (* call to Heron's formula function *) Which is also syntactic sugar for: fun area shape = case shape of Circle (_, r) => 3.14 * r * r | Square (_, s) => s * s | Triangle (a, b, c) => heron (a, b, c) If I were to implement the function like: fun area shape = case shape of Circle (_, r) => 3.14 * r * r | Square (_, s) => s * s and forget to include the Triangle case, I would get a compiler error: "match nonexhaustive". Furthermore if I were to include a redundant case or an unreachable case, the compiler would also throw an error informing me of that. Very useful in preventing runtime errors, and languages like Java or C/C++ simply do not provide this.
    - Locke1689 12y ago
      Yes, that is how pattern matching works, and no, it has nothing to do with parametric polymorphism. No plans to add extra sugar to immediately switch on the arguments of a function, but I'm pretty sure that switch(arg) is not terrible overhead. I've addressed exhaustivity in a different comment.

_random_ 12y ago

I prefer C# + average pattern matching + first-class IDE support to F# + first-class pattern matching + basic IDE support. C# without pattern matching is not an option :).

dragonwriter 12y ago

> I probably didn't get it, but what I thought I saw was a bunch of cool FP concepts bolted on top of a pretty long-in-the-tooth OO language. Well, yeah, if providing a good transition path for Java developers and a solid Java two-way interop story (including low-cognitive-overhead mapping of Java APIs) wasn't important, Scala would just be Haskell. > Perhaps we should start defining languages by what they don't do? There's plenty of languages that are defined by relatively pure adherence to a particular model and not letting you do things outside of it. Neither Scala nor C# have ever been among them (Java -- for one model of OOP -- and Haskell for pure functional programming are examples, not being that way is one of the things that distinguished C# from Java.) > Could somebody explain to me what we would like to achieve with this? With, what, exactly -- pattern matching in C#? Or the kitchen-sink approach to language features more generally?