函数式编程语言是否有更多机会进行编译时间优化？

我正在读《现实世界的函数式编程》一书。它从命令式和功能性编程语言之间的比较开始。它指出了函数式编程中的“值”和“表达式”与命令式编程中的“变量”和“函数”有何不同。通过讨论，我得出了一个想法-

与命令式编程语言相比，函数式编程语言有更多机会进行编译时间优化。

是真的吗

函数式编程语言可以做更多的编译时间优化。原因之一是纯度-并发是微不足道的，因为没有状态。因此，编译器可以采用两个分支并对它们进行并发，而无需更改程序的行为。

同时，可以在没有状态的情况下进行计算的任何内容（即，在haskell中为非一元形式的任何内容）都可以由编译器提前进行计算，但是这样的计算可能会很昂贵，因此可能只能部分完成。

另外，程序中不需要的任何东西都可以完全优化。

原则上，函数式语言比命令式对应语言有更多的编译时优化可能性，这可能是正确的。

但是，更有趣的是，如果它们实际上是在当前的编译器中实现的，以及这些优化在实践中的相关性（即，生产环境中惯用的“ realtime（TM）”代码的最终性能，并且具有先验可预测的编译器设置）。

例如，臭名昭著的“ 计算机语言基准游戏”的Haskell提交内容（虽然可能很糟糕-但现在还不存在-那里有明显改善的地方），给人的印象是花费了大量时间手动优化面临着“由于可能的编译器优化”的主张，这insert some property about FP languages here使得该优化看起来（目前至少）比相关现实更具理论可能性。

我很高兴在这一点上被证明是错误的。

在函数式中，通过程序的值流非常（对于编译器和程序员）都是可见的。这使编译器有很多余地来决定值的存储位置，保留值的时间等等。

用命令式语言，编译器向程序员承诺一个模型，其中大多数变量对应于内存中的实际位置，这些位置在定义的生存期内保持不变。潜在地，任何语句都可能会读取（或写入！）这些位置中的任何一个，因此编译器只能用寄存器分配替换内存位置，将两个变量合并到单个存储位置中，或者在对位置进行细致分析之后执行类似的优化。否则程序中可能会引用该变量。

现在，有两个警告：

• 在过去的五十年里，编程语言社区花费了大量精力（开发）进行这种分析的巧妙方法。有很多众所周知的技巧，例如套准着色等等，可以使大多数情况下更容易完成一些事情。但这会导致大型，慢速的编译器，并不断权衡编译复杂性和结果代码的质量
• 同时，大多数函数式编程语言也不是纯函数式的。很多真正需要做的，就像对I / O响应的事情节目本身无功能，所以没有编译器可以完全自由这些技巧，也没有语言避免了它们完全-甚至Haskell中，这是一个有点太纯粹出于我的口味（您的里程可能有所不同）只能控制和限制代码的非功能部分，而不能完全避免它们。

但是要回答一般性问题，是的，函数范式为编译器提供了很多自由空间来优化它在命令式设置中所没有的自由。