【问题标题】:What limits does scala place on the "acceptable complexity" of inferred types?scala 对推断类型的“可接受的复杂性”有什么限制?
【发布时间】:2012-07-10 15:21:33
【问题描述】:

根据Scala Language Spec

... 允许局部类型推断以限制推断的复杂性 bounds [类型参数]。必须理解类型的最小性和最大性 相对于可接受复杂性的类型集。

实际上有什么限制?

此外,适用于推断表达式类型的限制与适用于参数类型边界的限制是否不同?这些限制是什么?

【问题讨论】:

  • this blog 对此话题进行了一些有趣的讨论
  • 我建议发布到这里提到的 scala 语言邮件列表:scala-lang.org/node/199
  • 我不确定,但我认为这意味着例如我们有一个字符串列表,我们正在向其中添加一个 int。返回的不可变列表最终属于“Any”类型。所以类型的最大化
  • 这实际上是一个移动的目标,因为不同版本的 Scala 编译器有不同的限制。这已经改变了,我预计随着语言的不断发展,至少在不久的将来会继续改变。我对这个问题投了反对票,因为它不能像目前所说的那样得到回答。
  • @kevin 确实如此。我想我对 scala 2.9 最感兴趣,因为它是最近但稳定的。但我想知道会有多少变化。

标签: scala type-inference


【解决方案1】:

在推断类型时,编译器通常需要计算类型列表的最小上界 (LUB)。比如if (cond) e1 else e1的类型就是e1e1这两种类型的LUB。

这些类型可能会变得很大,例如在 REPL 中尝试:

:type Map(1 -> (1 to 10), 2 -> (1 to 10).toList)
scala.collection.immutable.Map[Int,scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int] with Serializable{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def dropRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def takeRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def drop(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def take(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]}; def dropRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def dropRight(n: Int): scala.collection.immutable.Seq[Int]...

commit 引入了一些健全性检查来限制此类推断类型的深度。

最近有一些工作将插件插入到编译过程中,以检测需要很长时间计算的推断类型,并建议可以谨慎使用显式类型注释的位置。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-07-17
    • 2013-02-24
    • 2012-05-02
    • 1970-01-01
    相关资源
    最近更新 更多