4 ms·

Would "extension interfaces" be equivalent to "type classes" in Haskell and/or "traits" in Scala or Rust?

joostdevries 9y ago
Being able to take an instance Person and make it be an Employee without changes to the Person class definitely sounds like ad hoc polymorphism. In Scala the equivalent of Haskells type classes is implicits though. Not traits. I do wonder if this 'extension interface implementation' feature would support the same inferencing that type classes in Haskell and implicits in Scala do. So that might be a difference.
- daxfohl 9y ago
  > In Scala the equivalent of Haskells type classes is implicits though. Not traits. Really? I'm not an expert but everything I've read until this implies the opposite. Besides, C# already has implicit conversions, and they're different from type classes in that they convert, not extend. Once an int is implicitly converted to a double, it's always a double from within the function that converted it, not just "representing" a double. So strictly less powerful than polymorphism. My understanding that type classes were the way out of that, and traits were Scala's equivalent. Is that not correct?
  - virtualwhys 9y ago
    Type classes in Scala typically entail a mix of features: implicits, traits, and higher kinded types. Assume you're thinking about C#'s extension methods, which in Scala are achieved via implicit classes.
  - lkitching 9y ago
    It's implicit arguments, not implicit conversions that enable type classes in Scala, although the class is usually represented by a trait e.g. trait Show[T] { def show(v : T): String } implicit object ShowInt extends Show[Int] { def show(i: Int) = i.toString } def showLine[T](v : T)(implicit show: Show[T]): Unit = { println(show.show(v)) }
    - daxfohl 9y ago
      Nice, that makes it more clear. Thanks!
MadsTorgersen 9y ago
There's a great proposal for adding type classes to C# here: https://github.com/MattWindsor91/roslyn/blob/master/concepts/docs/csconcepts.md https://github.com/MattWindsor91/roslyn/blob/master/concepts... And I discuss some ways that could be integrated with the extension everything proposal here: https://github.com/dotnet/csharplang/issues/164 https://github.com/dotnet/csharplang/issues/164 The problem with both is that there's a new notion of "shape" or "concept" that's different from interfaces. It would be nice to just use interfaces for this (which is what I hint at in the video), but that comes with its own downsides and limitations.

Being able to take an instance Person and make it be an Employee without changes to the Person class definitely sounds like ad hoc polymorphism. In Scala the equivalent of Haskells type classes is implicits though. Not traits. I do wonder if this 'extension interface implementation' feature would support the same inferencing that type classes in Haskell and implicits in Scala do. So that might be a difference.

daxfohl 9y ago
> In Scala the equivalent of Haskells type classes is implicits though. Not traits. Really? I'm not an expert but everything I've read until this implies the opposite. Besides, C# already has implicit conversions, and they're different from type classes in that they convert, not extend. Once an int is implicitly converted to a double, it's always a double from within the function that converted it, not just "representing" a double. So strictly less powerful than polymorphism. My understanding that type classes were the way out of that, and traits were Scala's equivalent. Is that not correct?
- virtualwhys 9y ago
  Type classes in Scala typically entail a mix of features: implicits, traits, and higher kinded types. Assume you're thinking about C#'s extension methods, which in Scala are achieved via implicit classes.
- lkitching 9y ago
  It's implicit arguments, not implicit conversions that enable type classes in Scala, although the class is usually represented by a trait e.g. trait Show[T] { def show(v : T): String } implicit object ShowInt extends Show[Int] { def show(i: Int) = i.toString } def showLine[T](v : T)(implicit show: Show[T]): Unit = { println(show.show(v)) }
  - daxfohl 9y ago
    Nice, that makes it more clear. Thanks!

MadsTorgersen 9y ago

There's a great proposal for adding type classes to C# here: https://github.com/MattWindsor91/roslyn/blob/master/concepts/docs/csconcepts.md https://github.com/MattWindsor91/roslyn/blob/master/concepts... And I discuss some ways that could be integrated with the extension everything proposal here: https://github.com/dotnet/csharplang/issues/164 https://github.com/dotnet/csharplang/issues/164 The problem with both is that there's a new notion of "shape" or "concept" that's different from interfaces. It would be nice to just use interfaces for this (which is what I hint at in the video), but that comes with its own downsides and limitations.