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老师。
