向Haskell添加ML样式模块有哪些主要的理论困难？

Question

众所周知，Haskell风格的类型类和ML风格的模块提供了不同的机制来指定接口。它们（可能）具有相同的功效，但实际上每种都有其自身的优点和缺点。

由于我在语言功能方面有点像包容性，我的问题是：在Haskell中添加ML样式模块有哪些主要的理论上的困难？我对以下几行的答案感兴趣：

• 现有的类型系统功能与ML风格的模块交互不畅？ （不良交互的一个例子是GADT和功能依赖，即使fundeps在技术上等同于相关类型！）

• 为了编译ML样式的模块，必须在编译器端放弃什么？

• ML样式模块如何与类型推断交互？

相关阅读：

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

Answer 1

进行比较的主要地方是，

• ML Modules and Haskell Type Classes: A Constructive Comparison。 Stefan Wehr和Manuel M.T. Chakravarty。在第六届ASIAN编程语言和系统研讨会论文集 - APLAS 2008，Springer-Verlag，LNCS，2008年。

• Modular Type Classes。 Derek Dreyer，Robert Harper和Manuel M. T. Chakravarty。在第34届ACM SIGPLAN会议论文集 - 编程语言原理信号研讨会上，ACM出版社，2007年。

• First class modules for Haskell，Mark Shields和Simon Peyton Jones。提交给第九届俄勒冈州波特兰市的面向对象语言基础国际会议（FOOL 9）。 20页。 2001年10月。

我实际上并没有意识到任何理论问题 - 至少已经提出了具体建议（并在原型中实施） - Shields和PJ论文有很多细节。然而，实施负担并非易事。

Answer 2

我认为没有任何重大的理论问题。你必须决定是否使用applicative functor。应用可能更多是Haskell风格。 但我认为任何将样式模块添加到Haskell的尝试都会怪诞，因为模块和类之间的重叠;有两种方法可以做很多事情。

Answer 3

Simon PJ认为ML风格模块的功耗/成本比较差，很难实现。见SPJ的slides from POPL 2003（到最后）。他还要求设计具有更好的功率/成本比例，但我不知道任何此类提议。