It is well known that Haskell-style typeclasses and ML-style modules offer different mechanisms for specifying interfaces. They are (possibly) equivalent in power, but in practice each has their own benefits and drawbacks.
Since I'm a bit of an inclusionist when it comes to language features, my question is this: What are the primary theoretical difficulties with adding ML-style modules to Haskell? I'm interested in answers along the following lines:
What existing type system features interact poorly with ML-style modules? (An example of poor interaction is GADT and functional dependencies, even though fundeps are technically equivalent to associated types!)
What things have to be given up on the compiler end in order to compile ML-style modules?
How do ML style modules interact with type inference?
Related reading:
The main place to do the comparison is,
ML Modules and Haskell Type Classes: A Constructive Comparison. Stefan Wehr and Manuel M.T. Chakravarty. In Proceedings of The Sixth ASIAN Symposium on Programming Languages and Systems - APLAS 2008, Springer-Verlag, LNCS, 2008.
Modular Type Classes. Derek Dreyer, Robert Harper, and Manuel M. T. Chakravarty. In Proceedings of The 34th Annual ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages, ACM Press, 2007.
First class modules for Haskell, Mark Shields and Simon Peyton Jones. Submitted to the Ninth International Conference on Foundations of Object-Oriented Languages (FOOL 9), Portland, Oregon. 20 pages. Oct 2001.
I'm not actually aware of any theoretical issues -- at least, concrete proposals have been made (and implemented in prototypes) -- the Shields and PJ paper have a lot of the details. The implementation burden however, is non-trivial.