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?

Related reading:

• Robert Harper’s post that provoked this question
• Discussion on Haskell Reddit

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.