Programming Languages PartC Week3学习笔记——子类型（Subtyping）的讨论

Subtyping From the Beginning

需要一种包含可修改fields的records，并且具有type system，支持subtyping的语言。我们学过的多种语言都不符合这种要求，因此需要我们自定义一种语法（假定一种语言语法）。

根据上述语法规则，下面的程序（类似子类应用在父类的场合）不会通过类型检测，因为type system此时会认为c不符合p的类型。这是不合理的，因为我们调用distToOrigin时不会用到color这个额外的field。

尽管我们不希望拥有错误field的类型变量被调用（应该在type checking时阻止），但也不应该阻止额外的field。

subtyping是实现这种想法的优雅手段。

The Subtype Relation

为了解决上一节的问题，我们需要在我们的语法规则中增加两条新的规则，一是subtyping的语法，二是新的类型检测规则。（但蓝字部分是唯一需要添加到类型规则中的部分）

subtype不是一种Option

subtype需要遵守的四个规则：

• 宽度：超类型拥有具备相同类型的子类型fields的子集
• 可排列性：超类型拥有的field子集元素可以是不同顺序
• 传递性：子类型可传递
• 自反性：任何type都是自己的子类

Depth Subtyping

sphere显然不是circleY要求的参数的子类型，除非去掉其中的r，或者去掉center。但这不是我们想要的方式。很自然的想法是，我们可以添加新的规则，当record中某个field是子类型时（所有fields值都必须是子类型（注意子类型的自反性）），这个record也是子类型。这种方式叫做深度subtyping，有点类似C++的深拷贝的思想。

但这种做法不值得我们去实现，因为它打破了稳定性soundness。

如果field不能修改，那么depth subtyping就是稳定的。

Optional: Java/C# Arrays

Java或者C#中，如果t1是t2的子类型，那么t1的数组也是t2的数组的子类型。这与上一节的depth subtyping类似，也会造成问题。

为什么允许这样的操作

null可以为一些不存在的对象或方法兜底，就像ML中的Option（其中的None）

Function Subtyping

对于函数本身，如果具有subtyping的特性

例子：

新的规则，如果函数返回值是子类型，函数是子类型

但如果函数参数是子类型，函数本身不应该是子类型，否则不稳定。这里值得注意的是，因为子类型会比超类型多出来一些field，所以才会导致函数子类型不稳定。

假如参数本身是超类型（少一些field），那么函数反而可以构成稳定的子类型

上述稳定的规则可以同时使用

这一节最后强调contravariant in argument的时候老师好可爱O(∩_∩)O哈哈~

Subtyping for OOP

类和类型的区别：

Generics Versus Subtyping

泛型与子类型

泛型擅长的：

子类型不擅长作为类型”容器“，向下转型是个问题：

子类型擅长的：

对于没有子类型的语言，向函数传递不同的getter和一个泛型来实现子类型的功能

Bounded Polymorphism

混合多态，将泛型和子类型混合使用

例子：

***Summarizing All We Have Learned

总结全部课程内容

首先是课程目标：

我们学到的内容：

几种语言的对比：

要点总结：

其一 是不可修改的好处：

其他要点：

学以致用：

最后就是本课程的saying goodbye环节。整个课程学下来收货还是很多的，函数式编程确实开阔了眼见，也学到了很多程序语言设计和编程哲学，很感谢Dan Grossman老师。