Чи компілятор для залежного типу набагато складніше, ніж інтепретер?

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

Так

Чи правильно моє наївне враження?
Якщо це правильно, будь-який приклад / ресурси щодо впровадження статично перевіреної мови, що підтримує залежний тип?

type-systems compilers dependent-type

— молікто
джерело

Ні, оскільки ви можете звести залежні типи проблеми компіляції до відомої проблеми: (1) тип перевірити програму за допомогою інтерпретатора; (2) витягнути програму на OCaml / Haskell / що завгодно; (3) компілювати за допомогою ocamloptабо GHC :-) (До речі, це підхід Кока та

— Агди

Відповіді:

Це цікаве питання! Як підказує відповідь Ентоні, можна використовувати звичайні підходи до складання незалежної функціональної мови, за умови, що у вас вже є перекладач для оцінки термінів для перевірки типу .

Такий підхід застосовує Едвін Брейді. Зараз це концептуально простіше, але воно втрачає швидкісні переваги компіляції під час перевірки типу. Це було вирішено декількома способами.

По-перше, можна реалізувати віртуальну машину, яка збирає терміни в байт-код на льоту, щоб виконати перевірку перетворення. Це ідея, vm_computeреалізована в Coq Бенджаміна Грегуара . Мабуть, є і ця теза Дірка Кліблатта з цієї точної теми, але внизу фактичний машинний код, а не віртуальна машина.

По-друге, можна генерувати код на більш звичайній мові, який після його виконання перевіряє всі перетворення, необхідні для перевірки набору відповідної програми. Це означає, що ми можемо використовувати Haskell, скажімо, для перевірки модуля Agda. Код можна компілювати та запустити, і якщо він приймає, тоді код на мові залежного типу можна вважати добре набраним (помилки в реалізації та заборони компілятора). Я вперше почув такий підхід, запропонований Матьє Босфлюгом .

$^*$

— коді
джерело

Трохи язик-щокою: чому б ви не турбувалися писати компілятор, якщо у вас перекладач робить перевірку типу? Зрештою, більшість (усіх?) Серйозних користувачів залежно набраних мов програмування дбають лише про перевірку типу, використовуючи мову як помічник перевірки. Я, звичайно, ніколи фактично не запускав жодної з моїх програм Agda або Coq. Тож якщо ви дбаєте про швидкість, чи не хочете ви збирати конверсії типів?

— Мартін Бергер

Рішення 2 і 3 вирішують це питання: ви складаєте код, який перевіряє чітку типовість (зокрема, виконує перетворення типів). Друге моє зауваження полягає в тому, що ви дійсно хочете запускати залежно введений код у деяких ситуаціях (див. Idris, Ur / Web).

— коді

Також: певною мірою рішення 1 вирішує це також, розмиваючи рядки між інтерпретатором і компілятором.

— коді

Цікаво, чи можна використовувати техніку проекції футурами для прискорення перекладача, ефективно закінчуючи компілятором?

— Стівен Шоу

Єдине, що я бачив - це Unison unisonweb.org/2017-10-13/scala-world.html

— Стівен Шоу

Кандидатська дисертація Едвіна Брейді визначає, як побудувати компілятор для залежно введеної мови програмування. Я не експерт, але я б сказав, що це не надзвичайно важче, ніж реалізувати компілятор, подібний до системи F. Багато принципів досить схожі, а деякі - однакові (наприклад, компіляція суперкомбінаторів.) Теза охоплює багато інших проблем.

— Ентоні
джерело