众所周知，Haskell 风格的类型类和 ML 风格的模块为指定接口提供了不同的机制。它们（可能）在权力上是相等的，但实际上每个都有自己的优点和缺点。
由于在语言特性方面我有点包容主义者，所以我的问题是：将 ML 风格的模块添加到 Haskell 中的主要理论困难是什么？我对以下方面的答案感兴趣：
哪些现有类型系统功能与 ML 样式模块交互不佳？（交互不良的一个例子是 GADT 和函数依赖，尽管fundeps 在技术上等同于关联类型！）
为了编译 ML 风格的模块，在编译器端必须放弃哪些东西？
ML 样式模块如何与类型推断交互？
相关阅读：
进行比较的主要地方是，
ML 模块和 Haskell 类型类：建设性比较。Stefan Wehr 和 Manuel MT Chakravarty。在第六届亚洲编程语言和系统研讨会论文集 - APLAS 2008，Springer-Verlag，LNCS，2008。
模块化类型类。Derek Dreyer、Robert Harper 和 Manuel MT Chakravarty。在第 34 届 ACM SIGPLAN - SIGACT 编程语言原理研讨会论文集上，ACM 出版社，2007 年。
Haskell 、Mark Shields 和 Simon Peyton Jones的一流模块。提交给俄勒冈州波特兰市第九届面向对象语言基础国际会议 (FOOL 9)。20 页。2001 年 10 月。
我实际上并没有意识到任何理论问题——至少，已经提出了具体的建议（并在原型中实施）——Shields 和 PJ 论文有很多细节。然而，实施负担并非微不足道。
我认为没有什么大的理论问题。您必须决定是否使用应用函子。Applicative 可能更像是 Haskell 风格。但我认为任何将 ML 样式模块添加到 Haskell 的尝试都是怪诞的，因为模块和类之间存在重叠；有两种方法可以做很多事情。
Simon PJ 认为 ML 风格的模块具有较差的功率/成本比，难以实施。请参阅POPL 2003中SPJ 的幻灯片（接近尾声）。他还要求设计具有更好的功率/成本比，但我不知道有任何此类提议。