在2013 年的这个问题中,Odersky 先生指出,“现在说”像 Scalaz 这样的库是否能够在 Dotty 下存在(至少在当前状态下)还为时过早,因为对高等和存在主义类型的阉割。
随着时间的流逝,Dotty 对 Scalaz & Cats 的影响是否已经阐明?内置效果器和记录等提议的功能会改变这些项目的范围吗?
我知道 Dotty 距离取代 scalac 仍有一段距离,但由于我正在考虑投入时间将纯功能结构和方法应用于我的工作,我认为考虑其旗舰库的未来很重要。
在2013 年的这个问题中,Odersky 先生指出,“现在说”像 Scalaz 这样的库是否能够在 Dotty 下存在(至少在当前状态下)还为时过早,因为对高等和存在主义类型的阉割。
随着时间的流逝,Dotty 对 Scalaz & Cats 的影响是否已经阐明?内置效果器和记录等提议的功能会改变这些项目的范围吗?
我知道 Dotty 距离取代 scalac 仍有一段距离,但由于我正在考虑投入时间将纯功能结构和方法应用于我的工作,我认为考虑其旗舰库的未来很重要。
Dotty 上最新的一个例子是 Chris McKinlay 的“ Scaling Scala ”(2016 年 12 月 15 日)(同一篇文章还提到了 Scalaz 和 Cats 的情况)
Martin Odersky一直在领导Dotty的工作,这是一种基于依赖对象类型(DOT) 演算(基本上是 Scala 的简化版本)和函数式编程 (FP) 数据库社区的想法的新型研究编译器。
从事 Dotty 开发的团队在现有技术的基础上取得了一些显着的进步,尤其是在编译时间方面。我问 Odersky,他认为 Dotty 架构有什么新颖之处并且可以帮助最终用户。他是这样说的:
想到两件事:
- 首先,它与形式化基础密切相关,为我们提供了如何设计完善的类型系统更好的指导。这将减少未来用户的惊喜。
- 其次,它具有本质上的功能架构。这使得它更容易扩展,更容易得到正确,并将导致更健壮的 API,其中编译器用作 IDE 和元编程的服务。
尽管 Dotty 开辟了许多有趣的语言可能性(特别是全谱依赖类型,la Agda和Idris),但 Odersky 选择优先考虑使其立即对社区有用。语言差异相当小,其中大多数是为了简化语言(如删除过程语法)或修复错误(不健全的模式匹配)或两者兼而有之(早期初始化程序)。
尽管如此,我还是忍不住问他是否有可能在某个时候出现全谱依赖类型最终出现在 Scala 中。这是他说的:
永远不要把话说绝了 :-)。事实上,我们目前正在与 Viktor Kuncak 合作将 Leon 程序证明器与 Scala 集成,这需要比我们现在拥有的更丰富的依赖类型。但它目前是严格的研究,具有完全开放的结果。
Scala 和 Dotty 团队正在密切合作以实现 Scala 2.x 和 Dotty 的融合,他们表示他们非常重视连续性。Scala 2.12 和 2.13 具有解锁在 Dotty 中孵化的功能(例如,存在类型)的语言标志,并且 Dotty 编译器具有 Scala 2 兼容模式。甚至还有一个迁移工具。