hubFS: THE place for F#

Hi,

There has been some complaining and speculating (including by yours truly) about typeclasses in F#, or rather, the lack thereof.

I've come up with a simple library in F# to emulate typeclasses (without type safety, of course - I haven't modified the compiler). It's a bit too lengthy to post here. If you're interested, read all about it at:

http://fortysix-and-two.blogspot.com/2009/01/poor-man-typeclass.html

I've already found a lot of use for this simple library in my own projects.

Let me know what you think.

Kurt

PS the title is blatanly stolen from Koen Claassen's excellent functional pearl 'A Poor Man's Concurrency Monad'. Otherwise no connection :)

---

http://fortysix-and-two.blogspot.com/

Can you explain what typeclasses give you that operator overloading doesn't?  The == example given in the Haskell documentation seems to me to be poorly chosen since that can be implemented using operator overloading without resorting to typeclasses (am I wrong about this?).

I think the main capability (more than overloading) that type classes provide is generic abstraction over all types that support this overloading.  Something like

Eq a => ...

means "for all types 'a' that support ==" which means you can write generic functions, rather than just one-off monomorphic functions, which use the 'overloaded operator' (member of the type class) in the function body.

A secondary capability, which is also quite useful, is that whereas 'overloading' is often 'a priori', adding a type as an instance to a type class is 'a posteriori'.  A third party can come along after the fact and make your type an instance of someone else's type class, even if your code knows nothing of their code.  (I am not sure if extension methods might be able to mimic this; probably not completely.)

That said, I haven't taken a close look at the "poor man's" version to know if anything there is different.

All the things Brian said are, more or less, also true for the poor man's version. Typeclasses allow overloading, period. Operator overloading is a specific kind of overloading.

One additional capability of typeclasses Brian didn't mention (although it needs another type system feature: type constructors), is that they allow to abstract over higher-order types, e.g.

class Functor f where
fmap :: a -> b -> f a -> f b

of which, for example, would be an instance. This is of course not possible with the library above - one would need the ability, besides typeclasses, to write a higher order type, e.g. in F#-ish notation 'a 't for any 't.

Kurt

---

http://fortysix-and-two.blogspot.com/

Hello,

AFAIK, Haskell typeclasses is extention of type system + shadowed argument (dictionary type -> func) for all functions that has classes in their signature.
If F# designers plan at some point to extend type system in some way similar to Haskell's, i will vote to ability to win some syntax sugar to play with that dictionary.

I found that a problem with .NET in general: The way .NET does something a little similar to type classes is through interfaces, but simple things, such as "all things that support addition and subtraction" cannot be expressed through interfaces. This makes .NET (and Java) generic functions much less powerful than either the compile-time approach of C++ templates or duck typing in Python. Of course, the new dynamic features in .NET (or Reflection, if we really need something now) can provide some of that functionality, but in a very crude way.

I'd definitely vote for either type classes or compile-time macros/templates in the .NET languages, F# in particular.