What are the primary theoretical difficulties with adding ML-style modules to Haskell?

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.