I mean, I know Tiobe isn't great, but the only ML-derivative I see on the top 50 is F#. ML and OCaml crack the top 100.
I mean, I know Tiobe isn't great, but the only ML-derivative I see on the top 50 is F#. ML and OCaml crack the top 100.
https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...
Also, I'm not sure what you mean by "manually pass that around". When you define a class in Haskell that inherits from a typeclass you reference that typeclass in the header of the new class. You follow the same approach in F# with interfaces.
type IEq<'a> =
abstract member eq: 'a -> 'a -> bool
but you then need to explicitly pass instances of this interface around into every method that requires it e.g. let allEq (s: 'a seq) (eq: IEq<'a>) = ...
whereas the haskell version would receive the Eq instance for the input type implicitly.Typeclass instances are globally unique for each type, which cannot be enforced with the interface solution. If you have an ordered map type, you can be sure the Ord instance used for insertion is the same that is used for retrieval. With the interface approach, clients cannot know which instance to use since there could be multiple implementations. The Haskell approach has its own problems, such as the proliferation of newtype wrappers to manage the dispatch mechanism.
Interfaces also hide the representation of one of their arguments (the receiver) whereas typeclasses are just a dictionary of functions.
https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_ar...
"Type classes are like interfaces/abstract classes, not classes itself
There is no inheritance and data fields (so type classes are more like interfaces than classes)....
For those more familiar with Java/C# rather than C++, type classes resemble interfaces more than the classes. In fact, the generics in those languages capture the notion of parametric polymorphism (but Haskell is a language that takes parametric polymorphism quite seriously, so you can expect a fair amount of type gymnastics when dealing with Haskell), so more precisely, type classes are like generic interfaces.
Why interface, and not class? Mostly because type classes do not implement the methods themselves, they just guarantee that the actual types that instantiate the type class will implement specific methods. So the types are like classes in Java/C#.
One added twist: type classes can decide to provide default implementation of some methods (using other methods). You would say, then they are sort of like abstract classes. Right. But at the same time, you cannot extend (inherit) multiple abstract classes, can you?
So a type class is sort of like a contract: "any type that instantiates this type class will have the following functions defined on them..." but with the added advantage that you have type parameters built-in, so:
class Eq a where
(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool
-- let's just implement one function in terms of the other
x /= y = not (x == y)
is, in a Java-like language: interface Eq<A> {
boolean equal(A that);
boolean notEqual(A that) {
// default, can be overriden
return !equal(that);
}
}
And the "instance TypeClass ParticularInstance where ..." definition means "ParticularInstance implements TypeClass { ... }", now, multiple parameter type classes, of course, cannot be interpreted this way."I remember years ago (15 years.. jesus I'm old) discovering OCaml and I couldn't believe how terse the language was for producing native code. If anything I don't like about OCaml syntax is that it actually has an enormous amount of syntactic sugar.
My complaint with OCaml was OCamlp and the tedium of creating modules and functors. While AdHoc poly (aka type classes) is not as flexible it is IMO easier to understand, generally less verbose and slightly more elegant than OCaml modules. I'm glad they added first class modules as I recall wanting something like that a long time ago.