But F# didn't bring along the beautiful module system from the MLs, nor does it have type classes. Polymorphism there is basically just the OO + generics variety found in C#. That can rub some people (like me) the wrong way.
Type classes are quite different from interfaces. How would you encode the Eq typeclass in F#? .Net has the IEqualityComparer<T> interface but you need to manually pass that around (unlike Eq instances) and you also lose the global uniqueness property.
You don't have to rely on the built in interfaces provided by .NET, you can create your own. Just like in Haskell in F# you can use pattern matching against types to define which of the equality operators to use.
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.
By 'pass around', I mean pass around instances, not definitions. You could define your own Eq interface in F#
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.
I'm not sure I understand all of what you've said, as I'm not familiar with Haskell, but there are at least some Haskell programmers have recognised the similarities between type classes and interfaces. Do you disagree with any of the following?
"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."
They explicitly said "an ML derivative that's not OCaml". It's not a big leap from that statement to "neither OCaml nor a Caml derivative" given the similarities between the languages. I'm really not at all surprised that if they want to discount OCaml as a successor ML, they'd want to discount F# as well, given the close relationship between the two. Like @hroman, I too was rather puzzled by your initial statement.
I'm sort of sick of hearing that OCaml has crappy or crufty syntax. I like OCaml's syntax. There is just a sea of useless algol brackets in so many languages. I was sort of sad that Rust fell victim to the damn bracket. At times I don't even think Scala is that much more succinct than modern Java 8 (ala bracket indentation fun).
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.
Guilty as charged.. I did learn OCaml first and from that official green HTML documentation which still appears to be green after 16 years :).
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.
For what it's worth, I think OCaml's syntax is one of its weakest points (not to mention syntax extensions...) and I have been writing OCaml 3 years longer than I've been writing Standard ML.
Well yes I agree if you compare OCaml to Standard ML its syntax is not as good and I do prefer Standard ML over it. However I prefer OCaml over Java, Javascript, Scala (and the bazillion other brace block languages that are the same), and yes even Haskell.
