> Scala的类型系统是惊人的(存在类型,变体,共同变体)
>由于宏的力量,一切都是Clojure中的一个库：(模式匹配,逻辑编程,非决定论,..)
题：
如果两个断言都是真的,为什么Scala的类型系统不是Clojure中的一个库？是因为：
>类型是图书馆不能正常工作的其中之一？ [即这些变化将以某种方式穿过每个现有的clojure库,包括clojure.core？]
> Scala的类型与clojure协议/记录基本不相容的概念？
> …？
解决方法
您对Scala有一个惊人的类型系统,而且关于Clojure是非常显着的元编程和语言扩展(尽管这不仅仅是宏….).
我可以想到的几个原因：
> Clojure是一种动态类型的语言,而Scala是静态类型的语言.强大的类型推论在语言中并没有太多的用处,您可以在这些语言中对输入的类型相对较少.
> Clojure已经有一个非常有趣的项目,添加打字作为图书馆(Typed Clojure),这看起来非常有希望 – 但是与Scala的方法截然不同,因为它是从一开始就设计用于动态语言(更多的是Typed Racket,更多的启发) .
Clojure哲学实际上阻止某些OOP概念(特别是实现继承,可变对象和数据封装).支持这些东西的类型系统(如Scala所述)不适合Clojure惯用语 – 最多只能被忽略,但是他们可以很容易地鼓励一种风格的开发,从而导致人们在以后遇到严重问题.
Clojure已经提供了解决您通常用其他语言类型解决的许多问题的工具 – 例如使用多态性协议.
> Clojure社区在简单性方面(在优秀视频“Simple Made Easy”的意义上,尤其是在39:30的幻灯片)中,有一个很强的关注点.虽然Scala的类型系统当然是惊人的,我认为这是一个将其描述为“简单”
>放入Scala风格的系统可能需要对Clojure编译器进行完全重写,并使其变得更加复杂.没有人似乎已经签署了迄今为止承担的这个特殊的挑战,而且有一个风险,即使有人愿意和能够做到这一点,这些变化可能会因为上述各种文化/技术原因被拒绝.
在没有对Clojure本身进行重大改变(我认为不太可能)的情况下,一个有趣的可能性是在Clojure中创建一个DSL,为特定的域提供Scala风格的类型推断,并将此DSL直接编译成优化的Java字节码.我可以看到,对于特定的问题域(例如大型矩阵的大规模数值数据处理),这是一个有用的方法.
