Які практичні питання стосуються типів перетину та об'єднання?

Я розробляю просту статичну типову функціональну мову програмування як досвід навчання.

Схоже, що типова система, яку я застосувала до цього часу, могла (з невеликою кількістю додаткових робіт) включати типи перетину та з'єднання, наприклад, у вас може бути:

• <Union String Integer>
• <Union Integer Foo>
• Перетин двох типів вище було б рівним Integer
• Союз двох типів був би <Union String Integer Foo>

Те, що це можливо, звичайно, не обов’язково означає, що це гарна дизайнерська ідея. Зокрема, я дещо занепокоєний труднощами в застосуванні для збереження типів, що не перетинаються та / або обробляються перекриттями.

Які плюси та мінуси включення таких функцій у систему типів?

Ось декілька речей, про які слід пам’ятати:

• Хоча ми зазвичай думаємо , що знаємо , що ми маємо в виду теоретико-множині перетину і об'єднання, було кілька різних бере на себе, що саме перетин і об'єднання типів є . Отже, варто зафіксувати це, перш ніж приступати до реалізації.
• S A S ⊏ $S \sqsubset A$"as" уточнює ") тоді як правила формування звичайних продуктів та сум є $S$$A$ S⊏ $$\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. Дизайн мови програмування Форсайта Дж. К. Рейнольдса
2. Типи перетину та обчислювальні ефекти Роуана Девіс та Френка Пфеннінга
3. Практична перевірка типу уточнення Роуана Девіс (дисертація)
4. Тринаправлена ​​перевірка типу Джошуа Данфілда та Френка Пфеннінга