Чому писати компілятор функціональною мовою простіше? [зачинено]

Я довго думав над цим питанням, але насправді не міг знайти відповіді в Google, а також подібне питання на Stackoverflow. Якщо є дублікат, вибачте за це.

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

Це правда? А якщо так, то чому так ефективно та легко писати їх функціональними мовами, а не імперативною мовою, як C? Крім того - хіба мовний інструмент у функціональній мові не повільніший, ніж у деяких мовах низького рівня, таких як C?

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

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

Багато завдань компілятора - це збіг шаблонів на деревних структурах.

І OCaml, і Haskell мають потужні та стислі можливості узгодження шаблонів.

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

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

В моєму останньому завданні компілятора ми використовували OCaml саме з цієї причини, маніпулюючи кодом C, це був просто найкращий інструмент для виконання цього завдання. Якби люди в INRIA побудували OCaml з різними пріоритетами, це могло б бути не таким вдалим.

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

/ me: повертається до моїх завдань Java трохи менш радісно ...

По суті, компілятор - це перетворення від одного набору коду до іншого - від вихідного до ІЧ, від ІЧ до оптимізованого ІЧ, від ІЧ до збірки і т. Д. Саме для цього призначені функціональні мови - чиста функція просто перетворення від одного до іншого. Імперативні функції не мають такої якості. Хоча ви можете писати цей тип коду імперативною мовою, функціональні мови спеціалізуються на ньому.

Дивіться також

F # шаблон дизайну

FP групує речі "за операцією", тоді як OO групує речі "за типом" і "за операцією", що є більш природним для компілятора / інтерпретатора.

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

Здається, всі пропустили ще одну важливу причину. Написати вбудовану мову домену (EDSL) для парсерів, які в звичайному коді дуже схожі на (E) BNF, досить просто.Комбінатори синтаксичного аналізатора, такі як Parsec, досить легко писати функціональними мовами, використовуючи функції вищого порядку та склад функцій. Не тільки простіше, але і дуже елегантно.

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

Це не єдиний спосіб зробити звичайніші рамки звичайно.