java - 为什么 Scala 将 for 实现为闭包？

Question

博客圈上最近发生的事件表明，Scala 可能存在的性能问题是它使用闭包来实现 for。

这个设计决定的原因是什么，而不是 C 或 Java 风格的“原语”——它将变成一个简单的循环？

(我在这里区分了 Java 的 for 和它的“foreach”构造，因为后者涉及隐式迭代器)。

更多细节，来自 Peter。 Scala 的这一点:

  object ScratchFor {
    def main(args : Array[String]) : Unit = {
      for (val s <- args) {
        println(s)
      }
    }
  }

创建 3 个类:ScratchFor$$anonfun$main$1.class ScratchFor$.class ScratchFor.class

ScratchFor::main 只是转发到伴生对象 ScratchFor$.MODULE$::main，它旋转了一个 ScratchFor$$anonfun$main$1(它是 AbstractFunction1 的一个实现)。

实际代码存在于 AbstractFunction1 的这个匿名内部实现的 apply() 方法中，它实际上是循环体。

我看不到 HotSpot 能够将其重写为一个简单的循环。不过，很高兴在这一点上被证明是错误的。

Answer 1

传统的 for 循环笨拙、冗长且容易出错。我认为添加到 Java、C# 和 C++ 的“for-each”循环足以证明这一点，但如果您需要更多详细信息，可以查看 Effective Java 的第 46 项。 .

现在，for-each 循环仍然比 Scala 的 for-comprehension 快得多，但它们也没有那么强大(而且更笨拙)，因为它们不能返回值。如果您想转换或过滤一个集合(或对一组集合执行这两项操作)，您仍然需要处理构建结果集合的所有机械细节此外 来计算值。更不用说它不可避免地使用一些可变状态。

最后，即使 for-each 循环足以用于集合，它们也不适合其他单子(monad)类(集合是其子集)。

所以 Scala 有一个通用方法来处理上述所有问题。是的，它速度较慢，但​​目标是让编译器有效地充分优化它，以便这不会成为障碍(当然，JIT 也可以在这里提供帮助)。

到目前为止，这还没有完成，但是 -optimise 已经在最新版本的 Scala 上减少了常见的 for-each 循环和 for-comprehensions 之间的很多差距。如果性能至关重要，您始终可以使用 while 或尾递归。

现在，可能 Scala 将通用的 for 循环或 for-each 循环作为专门针对性能问题的特殊情况(因为 for-comprehensions 可以完成它们所做的一切)。但是，这违反了指导 Scala 设计的两个原则:

1. 降低复杂性。是的，与某些人所说的相反， 是一个设计目标，而除了优化性能之外没有其他目的的特殊情况——即使存在针对性能情况的可行解决方案——会不必要地增加语言的复杂性。

2. 可扩展性。从某种意义上说，使用可以通过编写库来针对任何规模的问题扩展语言。这里的要点是，让编译器优化一个特定的类，例如 Range，将使用户无法创建性能同样好的替代类。