交差点タイプと共用体タイプの実際的な問題は何ですか？

学習体験として、静的に型付けされた単純な関数型プログラミング言語を設計しています。

私がこれまでに実装した型システムは、（少し余分な作業を行うことで）交差型と共用体型を組み込むことができるようです。

• <Union String Integer>
• <Union Integer Foo>
• 上記の2つのタイプの共通部分はプレーンです Integer
• 2つのタイプの結合は次のようになります <Union String Integer Foo>

もちろん、これが可能であるという事実は、必ずしもそれが優れたデザインアイデアであることを意味するわけではありません。特に、型をばらばらにしたり、重複を処理したりすることの実装の難しさを少し心配しています。

このような機能を型システムに組み込むことの長所と短所は何ですか？

留意するべきいくつかの事柄はここにあります：

• 一般に、集合論的な交差と結合の意味を知っていると思いますが、正確に交差と結合のタイプが何であるかについて、いくつかの異なる見解があります。そのため、実装に着手する前にこれを特定する価値があります。
• $S \sqsubset A$"as"洗練します） 一方、通常の積と和の形成規則は $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つは、プログラムのより正確なプロパティをかなり段階的に表現できることです。たとえば、依存型理論よりも大幅に少ない変換です。

簡単な読書リスト：

1. ジョンC.レイノルズによるプログラミング言語Forsytheの設計
2. Rowan DaviesとFrank Pfenningによる交差点タイプと計算効果
3. Rowan Daviesによる実用的な洗練タイプのチェック（論文）
4. Joshua DunfieldとFrank Pfenningによる三方向型チェック