<quote>That said my support for wanting type classes firmly rests on not being able to effectively define different monads at a much higher level of abstraction. Right now we are forced to implement each instance of a monad  and new up a builder object to use the syntactic sugar. Instead of Implementing one builder for the generic case, overriding where neccessary and not having to do the entire thing all over again, when I want to implement another monad. There are also other very nice ideas I have seen expressed in Haskell that need type classes to implement. For example <b></i> Design Patterns as Higher-Order Datatype Generic Programs<i></b>  http://www.wellquite.org/non-blog/videos/hug_hodgps.flv You can find the slides for the presentation on the london hug website. This is a beautiful thing which I would love to be able to experiment with in the context of .Net. I am sure there are other nuggets of beauty out there which I dont know about. </quote> I haven't looked at that specific example, but usually these things (if you want to look at some advanced Haskell type hackery: http://okmij.org/ftp/Haskell/types.html, e.g. stronly type heterogeneous collections) are applications on top of the complete Haskell type system, which is more than "just" type classes. Higher order types come to mind. Some need quite experimental extensions to Haskell98. Also for efficiently abstracting monads, you also need higher order types, for which you need to introduce a kind system and what not. Combine this with the OO type system already in F# (Haskell doesn't need to worry about that), I think this is quite the language design challenge (for one, the CLR does not support higher order types) I'm just saying: I don't think it should be the goal of F# to support all of Haskell or vice versa - at this point I'd rather see F# play out its strengths. There are some cool language features in F# that are not in Haskell (active patterns, quotations, subtyping,...). I like the concept of type classes as well, but you can get around the limitations with some extra work using reflection or code generation, for which there is ample .NET support. Kurt

Hi,

There's something like this, but only for inline values. And the syntax is ugly (have a look in fslib/prim-types.fs).

I wish the syntax could be improved, and I wish I could get this:

1
2
3
4
5
6
7
8

> let inline f x = x.Length;;


val inline f :
  ^a ->  ^b

when ( ^a ) : (member Length :  ^a ->  ^b)

This currently works with some operators (but only because they were defined in a special way). With inlining, we get something that looks like C++ templates or OCaml structural typing:

1
2
3
4
5
6
7
8
9
10
11
12
13

> let inline f x y = x + x * y;;

val inline f :


   ^a ->  ^c ->  ^d


    when ( ^a or  ^b) : (static member ( + ) :  ^a *  ^b ->  ^d) and


         ( ^a or  ^c) : (static member ( * ) :  ^a *  ^c ->  ^b)