CODEWITHSUNDEEP
f#fsharp-typeclasses
sdgfsdh
sdgfsdh

Reputation: 37045

What is missing using interfaces compared to true type-classes?

F# does not (currently) support type-classes. However, F# does support the OOP aspects of C#.

I was wondering, what is lost doing this approach compared to true type-classes?

// A concrete type
type Foo =
  {
    Foo : int
  }

// "Trait" for things that can be shown
type IShowable = 
  abstract member Show : unit -> string

module Showable = 
  
  let show (showable : IShowable) = 
    showable.Show()

// "Witness" of IShowable for Foo
module Foo =

  let asShowable (foo : Foo) = 
    {
      new IShowable with
        member this.Show() = string foo.Foo
    }

// Slightly awkward usage
{ Foo = 123 }
|> Foo.asShowable
|> Showable.show
|> printfn "%s"

Upvotes: 2

Views: 179

Answers (2)

Fyodor Soikin
Fyodor Soikin

Reputation: 80744

Higher-kinded type classes are indeed impossible to model with interfaces, but that's just because F# does not support higher-kindedness, not because of type classes themselves.

The deeper thing to note is that your encoding isn't actually correct. Sure, if you just need to call show directly, you can do asShowable like that, but that's just the simplest case. Imagine you needed to pass the value to another function that wanted to show it later? And then imagine it was a list of values, not a single one:

let needsToShow (showable: IShowable) (xs: 'a list) = 
  xs |> List.iter (fun x -> ??? how do I show `x` ???)

No, this wouldn't do of course. The key is that Show should be a function 'a -> string, not unit -> string. And this means that IShowable itself should be generic:

// Haskell: class Showable a where show :: a -> String
type IShowable<'a> with 
  abstract member Show : 'a -> string

// Haskell: instance Showable Foo where show (Foo i) = show i
module Foo =
  let showable = { new IShowable<Foo> with member _.Show foo = string foo.Foo }

// Haskell: needsToShow :: Show a => [a] -> IO ()
let needsToShow (showable: IShowable<'a>) (xs: 'a list) =
  xs |> List.iter (fun x -> printfn "%s" (showable.Show x))

// Haskell: needsToShow [Foo 1, Foo 42]
needsToShow Foo.showable [ { Foo: 1 }; { Foo: 42 } ]

And this is, essentially, what type classes are: they're indeed merely dictionaries of functions that are passed everywhere as extra parameters. Every type has such dictionary either available right away (like Foo above) or constructable from other such dictionaries, e.g.:

type Bar<'a> = Bar of 'a

// Haskell: instance Show a => Show (Bar a) where show (Bar a) = "Bar: " <> show a
module Bar =
  let showable (showA: IShowable<'a>) = 
    { new IShowable<Bar<'a>> with member _.Show (Bar a) = "Bar: " + showA.Show a }

This is completely equivalent to type classes. And in fact, this is exactly how they're implemented in languages like Haskell or PureScript in the first place: like dictionaries of functions being passed as extra parameters. It's not a coincidence that constraints on function type signatures even kinda look like parameters - just with a fat arrow instead of a thin one.

The only real difference is that in F# you have to do that yourself, while in Haskell the compiler figures out all the instances and passes them for you.

And this difference turns out to be kind of important in practice. I mean, sure, for such a simple example as Show for the immediate parameter, you can just pass the damn instance yourself. And even if it's more complicated, I guess you could suck it up and pass a dozen extra parameters.

But where this gets really inconvenient is operators. Operators are functions too, but with operators there is nowhere to stick an extra parameter (or dozen). Check this out:

x = getY >>= \y -> getZ y <&> \z -> y + 42 > z

Here I used four operators from four different classes:

  • >>= comes from Monad
  • <&> from Functor
  • + from Num
  • > from Ord

An equivalent in F# with passing instances manually might look something like:

let x = 
  bind Foo.monad getY <| fun y ->
    map Bar.functor (getZ y) <| fun z ->
      gt Int.ord (add Int.num y 42) z

Having to do that everywhere is quite unreasonable, you have to agree.

And this is why many F# operators either use SRTPs (e.g. +) or rely on "known" interfaces (e.g. <) - all so you don't have to pass instances manually.

Upvotes: 2

Brian Berns
Brian Berns

Reputation: 17038

Your suggestion works for simple typeclasses that operate on a single value of a type, like Show. However, what happens when you need a typeclass that isn't so object-oriented? For example, when we want to add two numbers, neither one corresponds to OO's this object:

// not real F#
typeclass Numeric<'a> =                   // e.g. Numeric<int> or Numeric<float>
   abstract member (+) : 'a -> 'a -> 'a   // e.g. 2 + 3 = 5 or 2.0 + 3.0 = 5.0
   ...

Also, keep in mind that many useful typeclasses require higher-kinded types. For example, consider the monad typeclass, which would look something like this:

// not real F#
typeclass Monad<'m<_>> =                  // e.g. Monad<Option<_>> or Monad<Async<_>>
   abstract member Return<'a> : 'a -> 'm<'a>
   abstract member Bind<'a, 'b> : 'm<'a> -> ('a -> 'm<'b>) -> 'm<'b>

There's no good way to do this with .NET interfaces.

Upvotes: 4

Related Questions