hubFS: THE place for F#

Is there any plans on eventually adding Type Classes to F#?

I second this request. Type classes would be useful for creating generic functions for monads / computation expressions in F#. At the moment i tend to implement Haskell functions like 'sequence' for each monad. This works because i have used only a few custom monads so far and monads are not central to F# like in Haskell. But it would be nice to have type classes if it is possible to add them.

This is a regularly recurring request. In the Expert F# book it's writen somewhere that this is actually under consideration, but since the F# team currently seems to be focused on productization of F#, I don't expect any more big language addition like type classes until a next major version after productization.

Then again, what do I know ;)

Kurt

Yeah I remember the author of Expert F# making mention of that. If Type classes are going to be eventually included in F# I know it wont make it for the time of the release. But It would be nice to know if it will be included down the road. If it wont be included then a nice explanation of why not would also be nice.

I've seen type classes in Haskell. I don't think type classes are the best choise. Ducktyping may be better.

Hi,

Even if it's possible to get duck typing in F# (with reflection), it's something dangerous and we want to avoid it. Duck typing is based on dynamic typing.

You might mean "structural typing", this is what OCaml has. This is indeed a great feature, but this is not planned for F# (F# currenlty uses nominal typing and interfaces, like C#). Nominal typing was chosen by a design decision, and it will probably never be changed.

Laurent.

It seems I meant structural typing.

But F# has something like it, does not it? I mean the way default operators are defined.

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:

> 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:

> 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)

LOST:

I've seen type classes in Haskell. I don't think type classes are the best choise. Ducktyping may be better.

Would you care to elaborate on that?

It's just that I don't see the connection between subtyping and type classes...

thanks,

Kurt

I don't presume to know LOST's mental process when he posted his response on the thread. But I would suppose that he wanted a way of doing a statically typed version of ducktyping.

Something I agree would be useful in a statically typed language. All we would need to do is have some notation for saying what a type needs to support at the method declaration. While interfaces give us this ability to some extent, it requires that you make every type inherit from it or rather declare it in its declaration.

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
 Design Patterns as Higher-Order Datatype Generic Programs
 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.

birchoff:

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
 Design Patterns as Higher-Order Datatype Generic Programs
 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.

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

And I agree with you that F# should not implement haskell in .Net. everytime I think about suggesting a new feature that I see in haskell I do find myself asking the question of what it would bring to F#. That said I do beleive F#  shold provide a means to sub type and or inherit from other Builder classes for its implementation of Monadic computations, called Computational Workflows. This is really the only reason I want Type Classes, and if it oculd be done by the compiler without Type classes I would be very open to that solution. No matter what it is

Kurt:

There are some cool language features in F# that are not in Haskell (active patterns, quotations, subtyping,...)

Upcoming GHC version 6.10 will also have view patterns.