[lomnakkus]

Agreed on the ML module system. It's a damn shame that Haskell has this anemic probably-historical-accident namespacing-only module system that we're stuck with. On the plus side, there seems to be some real impetus to implement the Backpack system, though there are still unexplored points in the design space behind Backpack, especially wrt. type classes.

FWIW, I think type classes are actually what make Haskell more appealing to me than O'Caml, even though O'Caml's modules technically subsume type classes (for most purposes anyway). In practice it just gets too verbose.

That, and enforced purity.

[jordwalke]

One thought on the verbosity of type classes vs. ML modules/functors: As a framework developer, if I have a more powerful abstraction (supposing ML functors/modules really are more powerful), then even if abstracting is more verbose, it might result in an even better end-developer experience, if that explicitness is limited to the core internal part of the framework.

In other words, that verbose application of functors etc, might only need to be written once in the internals of the framework, but could enable more powerful features for users of the framework with little or no additional verbosity. This is just one thing I've noticed happen in a very specific case and it might not be true in general. Really learning Haskell type classes is still on my list of things to do, so please forgive me if I've misspoken.

[lomnakkus]

That was actually my main objection to modules vs. typeclasses: The burden often seemed to land on the users of libraries. Typeclasses are usually effortless as a user, though there may be a multitude of sins[1] hidden behind them.

EDIT: Don't get me wrong, there are also advantages to being able to explcitly declare two structurally identical modules as different, but in practice I find that newtypes suffice.

[1] FlexibleInstances, UndecidableInstances, etc. :)