交集和并集类型的实际问题是什么？

我正在设计一种简单的静态类型的函数式编程语言，作为一种学习体验。

到目前为止，我已经实现的类型系统似乎可以（需要做一些额外的工作）合并交集和并集类型，例如，您可以：

• <Union String Integer>
• <Union Integer Foo>
• 上面两种类型的交集将是一个普通的 Integer
• 两种类型的联合是 <Union String Integer Foo>

当然，这是可能的事实并不一定意味着它是一个好的设计思想。特别是，我有点担心保持类型不相交和/或处理重叠的实现困难。

在类型系统中合并此类功能的利弊是什么？

这里有几件事要牢记：

• 尽管我们通常认为我们知道集合理论交集和并集的含义，但对于交集和并集的确切类型有几种不同的理解。因此，在开始实施之前，有必要对此加以固定。
• 我认为对于理解交集和并集非常重要的一个元素是类型细化的概念，本质上是程序具有某种固有的“原型”（例如，“ foo是从整数到整数的函数”）的想法。然后进行精炼以表示更精确的属性（例如，“ foo将偶数变为偶数，将奇数变为奇数”）。有了精化的概念，区分交集和并集与乘积和总和的关键特性是，只有在对相同原型进行精化的情况下，两种类型的交集/联合才能形成。换句话说，交集和并集的类型形成规则可以这样表示（请阅读“$S \sqsubset A$“，因为”细化了 “） $S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ ，而对于普通的产品和和的形成规则是 $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• 由于交集和并集可用于对程序的运行时行为进行更精确的断言，因此键入对评估顺序很敏感是很自然的。例如，下面的论文（2）和（4）解释了为什么对于类似ML的语言，对于交集和并集的“显而易见的”（相当标准的）键入和子类型输入规则实际上是不正确的（由于存在副作用和非终止）。你被警告了！
• 由于类似的原因，全局类型推断通常变得不切实际或无法确定。实际上，整个“主体类型”的概念可以说是一条红鲱鱼，因为一个函数可能会满足许多与其预期用途无关的不同属性（例如，“ foo将质数取大于7的整数”）。取而代之的是，用于相交和并集的实用方法（请参阅（3），（4））通常基于推理和检查的组合。

我想上述某些观点听起来可能是负面的，尽管我不会称它们为“缺点”，而只是称它们为交集和并集类型的“现实”。另一方面，从语言设计的角度来看，努力支持交集和并集（并使它们正确！）的一个原因是，它们允许以相当增量的方式表示程序的更精确属性，因此需要比依赖类型理论要少得多的大刀阔斧的转变。

简要阅读清单：

1. John C. Reynolds 设计的Forsythe编程语言
2. 罗恩·戴维斯和弗兰克·芬宁的交叉点类型和计算效果
3. Rowan Davies的实用细化类型检查（论文）
4. Joshua Dunfield和Frank Pfenning的三向类型检查