language-agnostic - 我对类型系统的理解正确吗？

Question

以下陈述代表了我对类型系统的理解(在 Java 世界之外的实践经验太少)；请更正任何错误。

静态/动态的区别似乎很明确:

静态类型 语言为每个变量、字段和参数分配一个类型，编译器防止不兼容类型之间的分配。示例:C、Java、帕斯卡。

动态类型 语言将变量视为可以容纳任何您想要的任何东西的通用箱 - 仅在运行时检查(如果有的话)类型，当您实际对值执行操作时，而不是在您分配它们时。示例:Smalltalk、Python、JavaScript。

类型推断 通过从上下文推断类型，允许静态类型语言看起来像(并具有一些优点)动态类型语言，这样您就不必在大多数情况下声明它们 - 但与动态语言不同，您不能例如最初使用一个变量来保存一个字符串，然后为其分配一个整数。示例:Haskell、Scala

我不太确定强/弱区别，我怀疑它的定义不是很明确:

强类型 语言为每个运行时值分配一个类型，并且只允许执行为该类型定义的操作，否则会出现显式类型错误。

弱类型 语言没有运行时类型检查 - 如果您尝试对它不支持的值执行操作，结果是不可预测的。它实际上可能会做一些有用的事情，但更有可能的是您会收到损坏的数据、崩溃或一些无法解读的次要错误。

似乎至少有两种不同类型的弱类型语言(或者可能是一个连续体):

在 C 和汇编程序中，值基本上是比特桶，所以一切皆有可能，如果您让编译器取消引用以 null 结尾的字符串的前 4 个字节，您最好希望它引导到不包含合法机器代码的地方。

PHP 和 JavaScript 一般也被认为是弱类型，但不要认为值是不透明的位桶；但是，它们将执行隐式类型转换。

但是这些隐式转换似乎主要适用于字符串/整数/浮点变量——这真的保证分类为弱类型吗？还是这些语言的类型系统可能会混淆错误的其他问题？

Answer 1

关于静态和动态类型 你死在钱上了。静态类型意味着程序在执行之前会被检查，并且程序可能会在启动之前被拒绝。动态类型意味着在执行过程中检查值的类型，并且类型不佳的操作可能会导致程序停止或以其他方式在运行时发出错误信号。静态类型的一个主要原因是排除可能有这种“动态类型错误”的程序。

Bob Harper他认为动态类型语言可以(并且应该)被认为是具有单一类型的静态类型语言，Bob 称之为“值”。这种观点是公平的，但它仅在有限的情况下有用，例如试图准确了解语言的类型理论。

尽管我认为您掌握了这个概念，但您的项目符号并没有明确说明 类型推断只是静态类型的一个特例 .在大多数具有类型推断的语言中，类型注释是可选的，但不一定在所有上下文中。 (例如:ML 中的签名。)高级静态类型系统通常让您在注释和推理之间进行权衡；例如，在 Haskell 中，您可以键入更高级别的多态函数(位于箭头左侧)，但只能使用注释。因此，如果您愿意添加注释，您可以让编译器接受一个在没有注释的情况下会被拒绝的程序。我认为这是类型推断的 future 浪潮。

“强”和“弱”类型的概念我将描述为 没用 ，因为它们没有普遍认可的技术含义。强类型一般意味着类型系统没有漏洞，而弱类型意味着类型系统可以被颠覆(使任何保证失效)。这些术语经常被错误地用于表示静态和动态类型。要看到区别，想想 C:该语言在编译时进行类型检查(静态类型)，但有很多漏洞；您几乎可以将任何类型的值转换为相同大小的另一种类型——特别是，您可以自由地转换指针类型。 Pascal 是一种旨在进行强类型化的语言，但众所周知的是有一个无法预料的漏洞:没有标签的变体记录。

随着时间的推移，强类型语言的实现经常会出现漏洞，通常使得运行时系统的一部分可以用高级语言实现。例如，Objective Caml 有一个名为 Obj.magic 的函数。它具有简单地返回其参数的运行时效果，但在编译时它将任何类型的值转换为任何其他类型之一。我最喜欢的例子是 Modula-3，其设计者将他们的类型转换构造称为 LOOPHOLE .

对于类型系统，我鼓励您避免使用“强”和“弱”这两个术语，而是准确地说出您的意思，例如，“类型系统保证在运行时不会发生以下类别的错误”(强) ，“静态类型系统不能防止某些运行时错误”(弱)，或“类型系统有漏洞”(弱)。仅将类型系统称为“强”或“弱”本身并不能很好地交流。