Scala在JVM上运行时有何妥协？

Scala是一种很棒的语言，但我想知道如果它有自己的运行时，该如何改进？

---

也就是说，由于JVM的选择而做出了哪些设计选择？

我所知道的两个最重要的折衷是：

• （“”）：它必须绕过Java编译（出于向后兼容性的原因，独立于JVM）
• 基元类型的集合：例如： Scala 2.8中处理数组的新方案。该方案不依赖装箱/拆箱和其他编译器魔法，而是依赖隐式转换和清单来集成数组

当涉及到管理泛型类型（带边界）时，这是两个主要的JVM限制：Java JVM没有在泛型对象中保留确切的类型使用，并且它有“基本”类型

---

但你也可以考虑：

• 尾部调用优化是，是（还有Scala 2.8引入）
• 需要进行模拟（Java不支持），并且很快就会进行
• 还需要模拟全混合机制
• 更一般地说，Scala引入的应用程序需要（对于大多数应用程序而言）在Java中生成：

为了涵盖尽可能多的可能性，Scala提供：

• 传统的班级类型
• 值类类型
• 不可为空的类型
• 单子类型
• 特质类型
• 单一对象类型（过程模块、实用程序类等）
• 复合类型
• 功能类型
• 案例类
• 路径相关类型
• 匿名类型
• 自我类型
• 键入别名
• 泛型类型
• 协变泛型类型
• 逆变泛型
• 有界泛型类型
• 抽象类型
• 存在类型
• 隐式类型
• 扩充类型
• 视图边界类型，以及
• 结构类型，当所有其他类型都失败时，允许一种duck类型

是与Martin Odersky（Scala的创建者）的讨论，包括Scala为与Java兼容而做出的妥协。文章提到：

方法的静态重载

既有特点又有阶级的

包含

null

指针

---

与其说是运行时的问题，不如说是文化宿醉：普遍平等、散列、toString

---

与VM的联系更为紧密：默认情况下严格的求值、不纯函数、异常。

+1表示通用等式和哈希。universal

toString

有什么问题吗？1）很容易意外地向用户显示

对象#toString

。2）

Collection[A]#toString

在显示

A

类型元素的方式上缺乏灵活性。请参见

scalaz.Show

，以获取替代方法。请注意：类型列表在中有详细说明（带有链接）