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

Question

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

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

相关阅读:

Answer 1

进行比较的主要地方是,

ML模块和Haskell类型类:构造性比较.Stefan Wehr和Manuel MT Chakravarty.在第六届ASIAN编程语言和系统研讨会论文集 - APLAS 2008,Springer-Verlag,LNCS,2008年.
模块化类型.Derek Dreyer,Robert Harper和Manuel MT Chakravarty.在第34届ACM SIGPLAN会议论文集 - 编程语言原理信号研讨会上,ACM出版社,2007年.
Haskell,Mark Shields和Simon Peyton Jones的一流模块.提交给第九届俄勒冈州波特兰市的面向对象语言基础国际会议(FOOL 9).20页.2001年10月.

我实际上并没有意识到任何理论问题 - 至少已经提出了具体建议(并在原型中实施) - Shields和PJ论文有很多细节.然而,实施负担并非无足轻重.

在2014年,它可能值得更新,参考[Backpack](http://plv.mpi-sws.org/backpack/),它试图将类似ML风格的模块系统带到GHC. (3认同)
@Lambdageek 截至 2017 年 11 月，此问题的作者 Edward Z. Yang 一直是 [Backpack 的活跃维护者](http://archive.is/https://ghc.haskell.org/trac/ghc/wiki/背包）至少从 2017 年 8 月开始。例如，请参阅他的 [博客文章](http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/) 关于被解释为代数时的类型类。还有他的 [博客文章](http://blog.ezyang.com/2014/08/whats-a-module-system-good-for-anyway/#comment-7357) 关于我们为什么需要模块。Backpack 部分基于 MixML，afaik 在核心语言中允许/具有 HKT。 (2认同)

Answer 2

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

Answer 3

Simon PJ认为ML风格模块的功率/成本比较差,很难实现.从POPL 2003(到最后)查看SPJ的幻灯片.他还要求设计具有更好的功率/成本比例,但我不知道任何此类提议.