Type systems--Introduction (持续更新中。。。)

学习这篇论文学习的笔记 原文 Type system -luca cardelli。

    Type System 的基本目的是防止在程序运行过程中发生执行错误。这个非正式的表达激发了对类型系统的研究，但需要细化阐述。它(这个表述)的准确性首先取决于一个相当微妙的问题，即什么是执行错误，我们将详细讨论这个问题。即使解决了这个问题，没有执行错误也是一个重要的属性。当这样的属性适用于所有可以在编程语言中表示的程序运行时，我们称该语言为Type sound(类型健全，类型安全)。事实证明，需要进行大量的仔细分析，以避免编程语言的类型健全性的错误的和令人尴尬的表述。因此，类型系统的分类、描述和研究已经成为一门正式的学科。

   类型系统(Type system) 的形式化需要开发精确的符号和定义，以及支持这些定义形式性质的详细证明。有时候这门学科相当的抽象（abstract）。然而，人们应该谨记，基本的动机是实用性: 抽象是出于需要，通常可以直接与具体的直觉联系。此外，为了有用和有影响力，并不需要完全应用形式化技术（即便不完整的使用，也可达相当有用的目的）。了解类型系统的主要原则可以帮助避免明显的和不那么明显的陷阱，并可以激发语言设计中的规律性和正交性（更改A不会更改B的属性）。

    当得到适当的开发，类型系统提供了判断语言定义重要方面的充分性的概念性工具。非形式化语言描述通常无法详细地指定语言的类型结构，从而无法实现明确的实现。 同一种语言的不同编译器实现稍微不同的类型系统是经常发生的。此外，许多语言定义被发现是类型不健全的，使得程序即使被类型检查器判断为可接受也会崩溃。理想情况下，formal类型系统应该是所有类型化编程语言定义的一部分。通过这种方式，类型检查算法可以根据精确的规范进行明确的度量，并且如果所有可能和可行的话，整个语言都可以示为类型健全。

    在本引言分中，我们将介绍类型、执行错误和相关概念的非正式命名法。我们将讨论类型系统的预期属性和好处，并回顾如何将类型系统形式化。引言中使用的术语不完全规范; 这是由于不同来源的标准术语本身不一致造成的。一般来说，在提到运行时概念时，我们避免使用“type”和“typing”这两个词; 例如，我们用dynamic checking来代替dynamic typing，并避免了常见但模糊的术语，如强类型（strong typing）。Defining Term 一节对术语进行了总结。

   在第2节中，我们将解释通常用于描述类型系统的符号。我们回顾了断言judgements(关于程序类型的形式断言)、类型规则type rules (断言之间的implication)和推导 derivation(基于类型规则的演绎)。在第3节中，我们回顾了广泛的简单类型(simple type)，它们的相似之处可以在common语言中找到，并详细介绍了它们的类型规则。在第4节中，我们介绍了一种简单但完整的命令式语言的类型规则。在第5节中，我们讨论了一些高级类型结构的类型规则:多态性和数据抽象。在第6节中，我们将解释如何使用子类型(subtyping)的概念来扩展类型系统。第7节是对我们已经忽略的一些重要主题的简要评论。在第8节中，我们讨论了类型推理问题，并给出了我们考虑过的主要类型系统的类型推理算法。最后，第9部分是对成果和未来方向的总结。

Execution Errors 执行错误
   执行错误最明显的迹象是出现意外的软件故障，例如非法指令故障或非法内存引用故障。

   但是，还有一些小的执行错误会导致数据损坏，而没有任何直接迹象（当时并不能发现）。此外，还有一些软件错误，例如除0和解引用nil(对象不存在的指针)，这些通常是类型系统无法防止的。最后，还有一些语言没有类型系统的概念，软件故障也不会发生。因此，我们需要仔细定义术语，从什么是类型开始。

Typed and untyped languages 有类型以及无类型语言

   在程序执行期间，程序变量可以认为是一个值的范围。这个范围的上界称为变量的类型（type of the variable）。例如，Boolean类型的变量x应该在程序的每次运行期间只假定布尔值。如果x的类型为Boolean，则布尔表达式not(x)在程序的每次运行中都有合理的含义。变量可以给定(非平凡)类型的语言称为类型化语言。

   不限制变量范围的语言称为无类型语言:它们没有类型，或者说，只有包含所有值的(单一通用类型)。在这些语言中，操作(operations)可能被应用于不适当的参数:结果可能是一个固定的任意值、一个错误、一个异常或一个未指定的效果。 纯λ-calculus是无类型语言的一种极端情况，在这种情况下不会发生任何错误:唯一的操作是函数应用程序，因为所有的值都是函数，所以该操作永远不会失败。

   类型系统是类型语言的一个组件，一般来说，该组件追踪程序中变量的类型以及所有表达式的类型。类型系统用于确定程序是否行为良好(如后面所讨论的)。只有符合类型系统的源程序才被认为是类型语言（typed language）的真正程序; 其他的（不符合类型系统的）应该在运行之前丢弃。

   一种语言的类型取决于它的类型系统的存在，无论类型是否实际出现在程序的语法中（类型系统存在但可能不显示的出现在语法中）。如果类型是语法的一部分，则类型语言为显式类型，否则为隐式类型。没有任何主流语言是纯隐式类型的，但是ML和Haskell等语言支持编写省略类型信息的大型程序片段; 这些语言的类型系统自动为这些程序片段分配类型。

Execution errors and safety执行错误以及安全性
区分两种执行错误是很有用的:一种是导致计算立即停止的错误，另一种是不被注意(一段时间)，然后导致任意行为的错误。前者被称为捕获错误，而后者被称为非捕获错误。

Untrapped Error 的一个例子是不正确地访问合法地址，例如，在没有运行时边界检查的情况下访问数组结束后的数据。另一个可能在任意一段时间内不被注意到的untrapped error是跳转到错误的地址: 那里的内存可能表示也可能不表示指令流。陷阱错误的例子有除零和访问非法地址:计算立即停止(在许多计算机体系结构上)。

如果一个程序片段不会导致未捕获错误发生，那么它就是安全的。所有程序片段都是安全的语言称为安全语言。因此，安全语言排除了最隐蔽的执行错误形式:那些可能不被注意到的错误。无类型语言可以通过执行运行时检查来加强安全性。类型化语言可以通过拒绝所有可能的不安全的程序来加强安全性。类型化语言也可以混合的使用运行时检查和静态检查（static checks）。

尽管安全性是程序的一个关键属性，但类型化语言很少专门关注消除未捕获错误。类型化语言通常旨在排除大类的捕获错误以及未捕获的错误。接下来我们将讨论这些问题。

Execution errors and well-behaved programs 执行错误以及程序行为良好
对于任何给定的语言，我们都可以将可能的执行错误的子集指定为禁止错误。禁止错误应该包括所有未捕获的错误，加上捕获错误的子集。如果一个程序片段没有导致任何被禁止的错误发生，那么它就被称为具有良好的行为，或者等效地称为行为良好。(与之相反的是有不良行为，或行为不端)。 特别是，行为良好的片段是安全的。所有(合法的)程序都具有良好行为的语言称为强检查（strongly checked）语言。

因此，对于给定的类型系统，对于强检查的语言，如下所示:
\begin{itemize}
\item 无未捕获错误发生(安全保证)。
\item 没有被指定为禁止错误的捕获错误发生。
\item 可能发生其他捕获错误;程序员负责避免这些错误。
\end{itemize}
类型化语言可以通过执行静态(即编译时)检查来强制执行良好的行为(包括安全性)，以防止不安全和行为不良的程序运行。这些语言是静态检查的;\red{检查的过程称为类型检查，执行这种检查的算法称为类型检查器}。通过类型检查器的程序称为良好类型的程序;否则，它就是类型不好的，这可能意味着它可能实际上是错误的，或者仅仅是不能保证它表现良好。静态检查语言的例子有ML、Java和Pascal(需要注意的是Pascal有一些不安全的特性)。

无类型语言可以通过不同的方式强制执行良好的行为(包括安全)，通过执行足够详细的运行时检查来排除所有禁止的错误。(例如，它们可以检查所有数组边界和所有除法操作，在发生禁止错误时生成可恢复的异常。)这些语言中的检查过程称为动态检查;LISP就是这种语言的一个例子。尽管这些语言既没有静态检查，也没有类型系统，但它们都是强检查的。

即使是静态检查语言通常也需要在运行时执行测试以实现安全性。例如，数组边界通常必须动态测试。语言被静态检查这一事实并不一定意味着执行可以完全盲目地进行。

一些语言利用它们的静态类型结构来执行复杂的动态测试。例如，Simula67的INSPECT, Modula-3的TYPECASE和Java的instanceof构造区分对象的运行时类型。这些语言仍然被认为是静态检查的(有点不恰当)，部分原因是动态类型测试是在静态类型系统的基础上定义的。也就是说，类型相等性的动态测试与类型检查器在编译时用于确定类型相等性的算法兼容。