[ihm]

OCaml's module system (and conventions associated with it) give a few advantages over Haskell.

- There are good conventions for naming and argument order (and named arguments!) so I don't have to memorize a bunch of different APIs. This is made possible by the module system. It could probably be solved in Haskell with better tooling.

- Modules allow you to, for lack of a better word, make your code more modular. Modules are essentially the same thing as what people use objects for in Java. They let you abstract implementation and program against a particular interface (i.e., a collection of types and values) easily in a way you can't really in Haskell.

[ricccardo]

Can you give a specific example? If you need abstract interfaces, what's wrong with Haskell's type classes?

[creichert]

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

[tel]

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.

[bad_user]

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.