On Dec 17, 2007 8:18 AM, Nicholls, Mark
The approach is deliberate...but I accept may be harder than it needs to be...I'm interested in Haskell because of the alleged power/formality of it's type system against the relatively weakness of OO ones...the irony at the moment is that they do not really seem to correspond directly....and OO type system seems to (loosely) correlate to Haskell type class system, and an OO class system (loosely) to Haskels type system, though in OOP's they are unpleasantly tangled.
When I was learning Haskell, I found it helpful to think this way: In an OO
system, classes describe objects. In Haskell, classes decribe types.
It may also be helpful to note that Haskell's class system can be emulated
in the language itself[1] by a technique known as "dictionary passing".
For example, the Eq class is equivalent to a function of type a -> a ->
Bool, for some a.
type EqD a = a -> a -> Bool
So any time I have a function that uses Eq,
foo :: Eq a => a -> a -> a -> a
foo a b c = if a == b then c else b
I could define an equivalent function without it
fooBy :: EqD a -> a -> a -> a -> a
fooBy eq a b c = if eq a b then c else b
The difference between foo and fooBy is that fooBy requires me to explicitly
provide the Eq dictionary, whereas the compiler takes care of providing it
to foo.
A lot of functions in Data.List exist in "foo" and "fooBy" forms.
[1] This isn't entirely true if we're talking about Haskell 98. Some classes
dictionaries can't be defined without an extension, but that extension is
widely supported and will almost certainly be in the next language standard.
--
Dave Menendez