为什么Scala的Type系统不是Clojure中的库

Question

我听说有人声称：

• Scala的类型系统很棒（存在类型，变体，共变体）

• 由于宏的强大功能，一切都是Clojure中的库:(模式匹配，逻辑编程，非确定性，......）

问题：

如果两个断言都是真的，为什么Scala的类型系统不是Clojure中的库？是因为：

• 类型是这些不适合作为库的东西之一吗？ [即变化会以某种方式穿过每个现有的clojure库，包括clojure.core？]

• Scala的类型概念与clojure协议/记录根本不兼容吗？

• ......？

Answer 1

这是一个有趣的问题。

你对Scala有一个惊人的类型系统肯定是正确的，并且关于Clojure对于元编程和语言的扩展是非常出色的（虽然这不仅仅是宏......）。

我能想到的几个原因：

1. Clojure是一种动态类型语言，而Scala是一种静态类型语言。具有强大的类型推断并不是在一种语言中使用，在这种语言中，您可以对输入类型的假设相对较少。
2. Clojure已经有一个非常有趣的项目，可以将输入添加为一个看起来非常有前景的库（Typed Clojure） - 但是它与Scala的方法非常不同，因为它是从一开始就为动态语言设计的（灵感更多）我相信Typed Racket。{/ li>
3. Clojure哲学实际上不鼓励某些OOP概念（特别是实现继承，可变对象和数据封装）。支持这些事情的类型系统（如Scala所做的那样）不适合Clojure成语 - 充其量它们会被忽略，但它们很容易鼓励一种可能导致人们在以后遇到严重问题的开发风格。
4. Clojure已经提供了一些工具，可以解决您通常使用其他语言类型解决的许多问题 - 例如使用多态性协议。
5. Clojure社区非常关注简洁性（在优秀视频的意义上"Simple Made Easy" - 特别是在39:30看幻灯片）。虽然Scala的类型系统确实令人惊叹，但我认为将其描述为“简单”
是一种延伸
6. 放入Scala风格的类型系统可能需要完全重写Clojure编译器并使其更加复杂。到目前为止，似乎没有人签约承担这一特定的挑战......而且即使有人愿意并且能够做到这一点，也有可能因上述各种文化/技术原因而拒绝这些变更。

如果Clojure本身没有发生重大变化（我认为不太可能），那么一个有趣的可能性就是在Clojure中创建一个DSL，为特定域提供Scala风格的类型推断并将此DSL直接编译为优化的Java字节码。我可以看到，对于特定问题域（例如，使用大矩阵进行大规模数值数据处理）是一种有用的方法。

Answer 2

简单地回答你的问题“......为什么Scala的类型系统不是Clojure中的库？”：

因为类型系统是scala编译器的一部分而不是scala库的一部分。 scalas类型系统的全部功能仅存在于编译时。由于类型擦除，JVM不支持这样的事情，因为它只会减慢执行速度。而且也没有必要。如果你有一个静态类型的语言，你不需要在运行时输入类型信息，除非你想做脏东西。

编辑：

@mikera jvm肯定能够运行scala编译器，我没有说那样的话。我只是说，jvm不支持类似的类型系统。它甚至不支持泛型。在运行时，所有这些类型都消失了。编译器会检查程序的正确性，并删除所有较高级别的类型/泛型。

示例：

val xs: List[Int] = List(1,2,3,4)
val x1: Int = xs.head

将在运行时看起来像这样：

val xs: List = List.apply(1,2,3,4)
val x1: Int = xs.head.asInstanceOf[Int]

但这没关系，因为编译器之前已经检查过它。当你使用反射时，你只能在这里遇到麻烦，因为你可以在列表中放置任何值，它会在运行时准确地在值被转换为Int的地方中断。

这就是为什么scala类型系统不是scala库的一部分，而是内置到编译器中的原因之一。

而且OP的问题是“......为什么Scala的类型系统不是Clojure中的库？”而不是“是否有可能为clojure创建一个类型系统，如scalas？”我完全回答了这个问题。