реалізація умовиводу типу

Я бачу тут кілька цікавих дискусій щодо статичного та динамічного набору тексту. Я, як правило, віддаю перевагу статичному набору тексту, завдяки перевірці типу компіляції, кращому документованому коду і т. Д. Однак я погоджуюсь, що вони дійсно захаращують код, якщо це робиться так, як це робить Java, наприклад.

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

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

Я знайшов наступні ресурси корисними для розуміння висновку типу в порядку зростаючої складності:

1. Глава 30 (Висновок про тип) вільно доступної книги PLAI , Мови програмування: Застосування та інтерпретація , наводить висновки типу на основі уніфікації.
2. Літній курс Інтерпретація типів як абстрактних значень представляє елегантні оцінювачі, перевірки типу, реконструктори типів та умовиводи, що використовують Haskell як метамову.
3. Глава 7 (Типи) книги EOPL , Основи мов програмування .
4. Глава 22 (Реконструкція типу) книги TAPL , Типи та мови програмування , а також відповідні реалізації OCaml recon і fullrecon .
5. Глава 13 (Реконструкція типу) нової книги DCPL , Концепції дизайну мовами програмування .
6. Підбір академічних робіт .
7. TypeInference компілятора закриття є прикладом підходу до аналізу потоку даних до виведення типу, який більше підходить для динамічних мов, ніж підхід Hindler Milner.

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

Я рекомендую ці дві доступні домашні завдання в ML, які ви можете виконати менш ніж за день:

1. Інтерпретатор PCF ( рішення ) для розминки.
2. Висновок типу PCF ( рішення ) для реалізації алгоритму W для висновку типу Хіндлі-Мілнера.

Ці завдання є з більш просунутого курсу:

1. Впровадження MiniML

2. Поліморфні, екзистенційні, рекурсивні типи (PDF)

3. Двонаправлена ​​перевірка типу (PDF)

4. Підтипізація та об'єкти (PDF)

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

http://www.plai.org/

Я спробую узагальнити абстрактну ідею з подальшими деталями, які я не знайшов одразу очевидними. По-перше, можна зробити висновок про тип, щоб генерувати, а потім вирішувати обмеження. Щоб створити обмеження, ви переглядаєте дерево синтаксису та генеруєте одне або кілька обмежень на кожному вузлі. Наприклад, якщо вузол є +оператором, операнди та результати повинні бути числами. Вузол, який застосовує функцію, має той самий тип, що і результат функції тощо.

Для мови без цього letви можете наосліп вирішити вищезазначені обмеження шляхом заміни. Наприклад:

(if (= 1 2) 
    1 
    2)

тут можна сказати, що умова оператора if має бути булевим, а тип оператора if такий самий, як тип його thenта elseречень. Оскільки ми знаємо 1і 2є числами, підставляючи, ми знаємо, що ifтвердження є числом.

Там, де все стає неприємним, і те, з чим я якийсь час не міг зрозуміти, має справу, нехай:

(let ((id (lambda (x) x)))
    (id id))

Тут ми прив’язані idдо функції, яка повертає все, що ви передали, інакше відому як функція ідентифікації. Проблема полягає в тому, що тип параметра функції xвідрізняється при кожному використанні id. Другий id- це функція типу a -> a, де aможе бути що завгодно. Перший - тип (a -> a) -> (a -> a). Це відоме як нехай-поліморфізм. Ключовим є вирішення обмежень у певному порядку: спочатку вирішити обмеження для визначення id. Це буде a -> a. Потім idу обмеження для кожного місця idможна використовувати свіжі, окремі копії типу , наприклад, a2 -> a2і a3 -> a3.

Це не було легко пояснене в Інтернет-ресурсах. Вони згадають алгоритм W або M, але не те, як вони працюють з точки зору вирішення обмежень, або чому він не заважає поліморфізму let: кожен із цих алгоритмів забезпечує порядок вирішення обмежень.

Я знайшов цей ресурс надзвичайно корисним, щоб пов’язати алгоритм W, M та загальну концепцію генерації та вирішення обмежень разом. Це трохи щільно, але краще, ніж у багатьох:

http://www.cs.uu.nl/research/techreps/repo/CS-2002/2002-031.pdf

Багато інших паперів там теж приємні:

http://people.cs.uu.nl/bastiaan/papers.html

Сподіваюся, це допоможе прояснити дещо каламутний світ.

На додаток до Хіндлі Мілнер для функціональних мов, ще одним популярним підходом до виведення типу для динамічної мови є abstract interpretation.

Ідея абстрактної інтерпретації полягає в тому, щоб написати спеціальний інтерпретатор для мови, замість того, щоб тримати середовище конкретних значень (1, false, закриття), воно працює над абстрактними значеннями, вони ж типи (int, bool тощо). Оскільки це інтерпретація програми на абстрактних значеннях, тому вона називається абстрактною інтерпретацією.

Pysonar2 - це елегантна реалізація абстрактної інтерпретації для Python. Він використовується Google для аналізу проектів Python. В основному він використовує visitor patternдля відправки виклику оцінки на відповідний вузол AST. Функція відвідувача transform приймає, contextв якому буде оцінюватися поточний вузол, і повертає тип поточного вузла.

Типи та мови програмування Бенджамін С. Пірс

Лямбда Кінцева, починаючи тут .