OCaml modules have many similar characteristics to Haskell type class[0]. One of the primary differences being that the Haskell type classes handle dictionary passing automatically and support ad-hoc polymorphism. This can be achieved with ML modules but requires bit more labor.

Haskell type classes can make it a bit easier to encode (and infer) interfaces but assume a single implementation per data type. ML modules do not make this assumption and support a higher degree of modularity as a result.

Robert Harper has some extremely good writing out there on this topic (and many more): https://existentialtype.wordpress.com/2011/04/16/modules-mat...

[0] - http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf

Type classes are far less direct to encode. One also requires existential types to get the modularity properties of ML modules and they are a burden to deal with in Haskell.

A good example of something easy to do with ML modules and hard to do in Haskell is the Cohttp library which is a HTTP stack that works using the Lwt async backend, the Async async backend, and a Javascript Lwt backend. It is merely modularized over that interface and you can plug in whatever backend you like.

There are examples of doing similar things (Reflex is modeled this way, e.g.) but it's hairier in Haskell.

I don't know much about Ocaml's modules, however Haskell's type-classes require global uniqueness, which makes them anti-modular. Another problem with Haskell's type-classes is that they are magical, in the sense that they aren't either types or values, hence combining type-classes is always an exercise in frustration. If you want to think of type-classes as being much like OOP interfaces, you're making a mistake. Ironically in Scala, which is the lesser FP language, type-classes are modeled by OOP interfaces and instances are values, so you won't get the same problems.