What are the primary theoretical difficulties with adding ML-style modules to Haskell?
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?
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.
I don't think there's any big theoretical problems. You'd have to make a decision about applicative functors or not. Applicative is probably more in the Haskell style. But I think any attempt at adding ML style modules to Haskell will be grotesque because the overlap between modules and classes; there will be two ways of doing many things.
Simon PJ has argued that ML style modules have a poor power/cost ratio, that they are hard to implement. See SPJ's slides from POPL 2003 (towards the end). He also calls for a design which has a better power/cost ration but I'm unaware of any such proposal.