Поліморфізм вищого рангу по відношенню до незмінених типів

У мене є мова, в якій типи за замовчуванням нерозкриваються, з виведенням типу на основі Гіндлі – Мілнера. Я хотів би додати поліморфізм вищого рангу, головним чином для роботи з екзистенційними типами.

Думаю, я розумію, як перевірити ці типи, але я не впевнений, що робити при складанні. В даний час я компілюю поліморфні визначення, генеруючи спеціалізації, подібно до шаблонів C ++, щоб вони могли працювати з неосмисленими значеннями. Наприклад, з даним визначенням f<T>, якщо програма посилається лише на f<Int32>і f<Char>, то у складеній програмі відображаються лише ті спеціалізації. (Я зараз припускаю складання цілої програми.)

Але, передаючи поліморфну ​​функцію як аргумент, я не бачу, як я можу статично генерувати правильну спеціалізацію, оскільки функція може бути обрана під час виконання. У мене немає іншого вибору, як використовувати подання в коробці? Або є спосіб вирішити це питання?

Моя перша думка була якоюсь - то чином закодувати rank- н поліморфізм , як 1 -го рангу, але я не вірю , що це можливо в цілому , так як формула конструктивної логіки не обов'язково мати пренексную нормальну форму.

Я трохи подумав про це. Основне питання полягає в тому, що загалом ми не знаємо, наскільки велике значення має поліморфний тип. Якщо у вас немає цієї інформації, вам доведеться якось її отримувати. Мономорфізація отримує цю інформацію для вас, спеціалізуючись на поліморфізмі. Бокс отримує цю інформацію для вас, ставлячи все в подання відомого розміру.

Третя альтернатива - відстежувати цю інформацію у видах. В основному, ви можете ввести різний вид для кожного розміру даних, і тоді поліморфні функції можна визначити для всіх типів певного розміру. Я намалюю таку систему нижче.

$$\newcommand{\bnfalt}{\;\;|\;\;} \newcommand{\rule}[2]{{\mathord{\array{#1}} \over {\mathord{#2}}}} \newcommand{\judge}[3]{{#1} \vdash {#2} : {#3}}$$ $$\begin{array}{llcl} \mbox{Kinds} & \kappa & ::= n \\ \mbox{Type constructors} & A & ::= & \forall a:\kappa.\; A \bnfalt \alpha \bnfalt A \times B \bnfalt A + B \bnfalt A \to B \\ & & | & \mathsf{ref}\;A \bnfalt \mathsf{Pad}(k) \bnfalt \mu \alpha:\kappa.\; A\\ \end{array}$$

Тут ідея високого рівня полягає в тому, що тип типу говорить вам, скільки слів потрібно, щоб викласти об’єкт в пам'ять. Для будь-якого заданого розміру легко бути поліморфним над усіма типами саме цього розміру. Оскільки кожен тип - навіть поліморфний - все ще має відомий розмір, компіляція не є більш важкою, ніж для C.

Правила впорядкування перетворюють цю англійську мову на математику і повинні виглядати приблизно так: Γ ⊢ A : n Γ ⊢ B :

$$\rule{ \alpha:n \in \Gamma} { \judge{\Gamma}{\alpha}{n} } \qquad \rule{ \judge{\Gamma, \alpha:n}{A}{m} } { \judge{\Gamma}{\forall \alpha:n.\; A}{m} }$$ Γ ⊢ A : m Γ ⊢ B : $$\rule{ \judge{\Gamma}{A}{n} & \judge{\Gamma}{B}{m} } { \judge{\Gamma}{A \times B}{n + m} } \qquad \rule{ \judge{\Gamma}{A}{n} & \judge{\Gamma}{B}{n} } { \judge{\Gamma}{A + B}{n + 1} }$$ $$\rule{ \judge{\Gamma}{A}{m} & \judge{\Gamma}{B}{n} } { \judge{\Gamma}{A \to B}{1} } \qquad \rule{ \judge{\Gamma}{A}{n} } { \judge{\Gamma}{\mathsf{ref}\;A}{1} }$$ $$\rule{ } { \judge{\Gamma}{\mathsf{Pad}(k)}{k} } \qquad \rule{ \judge{\Gamma, \alpha:n}{A}{n} } { \judge{\Gamma}{\mu \alpha:n.\; A}{n} }$$

Таким чином, кількісний коефіцієнт вимагає, щоб ви наділяли тип, на який ви перебуваєте. Аналогічно, спарювання - це незміщений тип пари, який просто розміщує поряд із в пам'яті (як тип структури C). Нерозчленовані спілки беруть два значення однакового розміру, а потім додають слово для тега-дискримінатора. Функції - це закриття, представлені, як зазвичай, вказівником на запис середовища та коду.$A \times B$$A$$B$

Посилання цікаві - вказівники - це завжди одне слово, але вони можуть вказувати на значення будь-якого розміру. Це дозволяє програмістам реалізувати поліморфізм до довільних об'єктів шляхом боксу, але не вимагає від них цього. Нарешті, коли явні розміри граються, часто корисно вводити тип прокладки, який використовує простір, але нічого не робить. (Отже, якщо ви хочете взяти роз'єднаний об'єднання int і пари int, вам потрібно буде додати прокладку першого int, щоб макет об'єкта був рівномірним.)

Рекурсивні типи мають стандартне правило формування, але зауважте, що рекурсивні випадки мають бути однакового розміру, а це означає, що вам зазвичай доводиться вставляти їх у вказівник, щоб узагальнити роботу. Наприклад, тип даних списку може бути представлений як

$$\mu \alpha:1.\; \mathsf{ref}\;(\mathsf{Pad}(2) + \mathsf{int} \times \alpha)$$

Таким чином, це вказує на значення порожнього списку, або пару int та покажчик на інший пов'язаний список.

Перевірка типу для таких систем також не дуже складна; алгоритм у моєму документі ICFP з Джошуа Данфілдом, Повна та проста двонаправлена ​​перевірка типу для поліморфізму вищого рангу застосовується до цього випадку майже без змін.

Здається, це ближче до проблеми компіляції, ніж до проблеми "теоретичної інформатики", тож вам, мабуть, краще запитати в іншому місці.

Взагалі, я думаю, що немає іншого рішення, ніж використання подання в коробці. Але я також очікую, що на практиці існує багато різних альтернативних варіантів, залежно від специфіки вашої ситуації.

Наприклад, представлення низькорівневих аргументів на низькому рівні зазвичай може бути класифіковано на дуже мало альтернативних варіантів, наприклад, цілочисельне або подібне, плаваюча точка чи покажчик. Тому для функції f<T>, можливо, вам справді потрібно лише генерувати 3 різні некомплектні реалізації, і ви можете представити поліморфну ​​як набір цих 3 функцій, тому інстанціювання T до Int32 - це просто вибір першого елемента кортежу, ...