像MLton这样的整个程序编译器创建了优化的二进制文件，部分原因是它们能够使用二进制文件的总来源来执行部分评估：积极地内联常量并在编译期间对它们进行评估直到卡住全部！
Gabriel Gonzalez's Morte已经在Haskell空间中对此进行了公开的探讨。
现在我的理解是，Haskell并没有做太多的事情 - 如果有的话。我理解的原因是它与分离编译是对立的。这对于禁止跨源文件边界进行部分评估是有意义的，但似乎文件内部分评估仍然是一种选择。
据我所知，仍未执行文件内部分评估。
我的问题是：这是真的吗？如果是这样，执行文件内部分评估的权衡是什么？如果没有，那么什么是一个示例文件，通过将更多功能放入同一个文件，可以提高编译性能？
（编辑：为了澄清上述内容，我知道有很多问题需要做出最好的减排措施 - 很多都是不可判断的！我想知道在“工业实力”中做出的权衡取舍如果有任何有趣的事情可以讨论，那么编译器的单独编译生活在选择正确的等式理论的水平上。编译速度或文件膨胀等问题更多地涉及我感兴趣的范围。同一空间中的另一个问题可能是：“为什么不能通过单独编译每个模块，让API暴露，然后将它们全部链接在一起，MLton得到单独的编译？”）
答案 0 :(得分：5)
这绝对是一小部分人感兴趣并正在追求的优化。用于查找相关信息的Google搜索字词是＆＃34; supercompilation＆＃34;。我相信目前至少有两种方法在浮动。
似乎最大的权衡之一就是编译时间资源（时间和内存），而目前支付这些费用的表现胜利似乎有些不可预测。还剩下一些工作。一些链接：