GHC部分评估和单独编译
像MLton这样的全程序编译器创建优化的二进制文件，部分原因是它们能够使用二进制文件的总体来源来执行部分评估：在编译过程中积极地内联常量并评估它们，直到卡住为止！
Gabriel Gonzalez的Morte在Haskell空间中公开探讨了这一点。
现在我的理解是，Haskell并没有做太多的工作 - 如果有的话。 我所理解的引用理由是分离编译是对立的。 这对于禁止跨源文件边界进行部分评估是有意义的，但似乎文件部分评估仍然是一种选择。
据我所知，虽然文件中的部分评估仍未执行。
我的问题是：这是真的吗？ 如果是这样，进行文件部分评估的权衡是什么？ 如果不是，那么通过将更多功能放入同一文件中，可以提高编译性能的示例文件是什么？
（编辑：为了澄清上述内容，我知道有很多问题需要执行最好的缩减集合 - 很多是不可判定的！我想知道在具有单独的“工业强度”编译器中进行的折衷如果在那里有任何有趣的事情要讨论，那么生活在一个高于选择正确的等式理论的水平上，编译速度或文件膨胀等更多的是我感兴趣的范围。同一空间中的另一个问题可能是： “为什么MLton不能单独编译每个模块，将API暴露出来，然后将它们链接在一起？”）
这绝对是一小部分人对此感兴趣并正在追求的优化。 谷歌搜索术语来查找关于它的信息是“超级编译”。 我相信目前至少有两种方法在浮动。
似乎编译时间资源（时间和内存两者）之间的一个重大折衷是，而且目前支付这些成本所获得的性能似乎有点难以预测。 还剩下相当多的工作。 几个链接：
上一篇: GHC Partial Evaluation and Separate Compilation
下一篇: GHC compilation bug?