1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type IFoo =
      type Bar
      abstract Baz: Bar -> Bar

type Foo() =
      interface IFoo with
           type Bar = int
           member self.Baz x = x + 1

type Foo2() =
      interface IFoo with
           type Bar(x) =
                 member bar.X = x
           member self.Baz(x) = x

let foo = Foo() :> IFoo
let foo2 = Foo2() :> IFoo

// Can't do this with generics
let x = [foo; foo2]

Also, the type the interface implementer implements is abstract to the outside world they don't know what it is they have to use the methods provided by the class. Another reason this is more useful than generics in certain cases is because it makes more sense in some cases. For example, if they had abstract type members it would make more sense to use abstract types this is also tue for IComparable. Another reason this is good is because you pass methods as parameters you can abstract them, you can pass values as parameters and you can abstract them, and you pass types as generic parameters , but you can't abstract them which I find strange. Finally, Something like this i believe is used in ML.

Although it's awkward, there's a way to faithfully encode this using generics. Unfortunately it requires adding a few extra types and makes the logic a bit inverted, but it works:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

type IFooUser<'r> =
  abstract Use<'x> : IFoo<'x> -> 'r
and IFoo<'x> =
  abstract Baz : 'x -> 'x
and IFoo =
  abstract Apply<'r> : IFooUser<'r> -> 'r

type Foo() =
  interface IFoo with
    member x.Apply(user) =
      user.Use { new IFoo<int> with member f.Baz(x) = x + 1 }

type Bar(x) =
  member bar.X = x

type Foo2() =
  interface IFoo with
    member x.Apply(user) =
      user.Use { new IFoo<Bar> with member f.Baz(x) = x }

let foo = Foo() :> IFoo
let foo2 = Foo2() :> IFoo

[foo; foo2]

F# type system is not as power as Haskell or Ocaml(which surprise me a bit as it seems to derive from).

For your particular same mentioned above, I can sort of mimic that with

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

 

type IFoo<'a> = interface
  abstract member bar: 'a -> 'a
end  

type Foo1() =   
  interface IFoo<int> with
    member self.bar(x) = x + 1

type Bar(x) = 
  member bar.x = x

type Foo2() =
  interface IFoo<Bar> with
    member self.bar(x) = x    

type MOFoo = A of IFoo<int> | B of IFoo<Bar>

let x = [ A (Foo1():> IFoo<int>);B(Foo2():> IFoo<Bar>)]      

Not very clean but not too bad. However, I agree that once these things get multiplied, it becomes unmanageable(I really like the Haskell type constructor and multi-param type). I use the member constraint as kind of substitute in my attempted generic monad implementation as a work around