Чи є у функціональних мов програмування більше можливостей зробити оптимізацію часу компіляції?

Я читав книгу «Функціональне програмування для реального світу». Він розпочався з порівняння імперативних та функціональних мов програмування. І в ньому зазначалося, чим «значення» та «вирази» у функціональному програмуванні відрізняються від «змінних» та «функцій» імперативного програмування. З обговорення я наче розробив ідею, що -

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

Це правда?

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

У той же час, все, що можна обчислити без стану (тобто все, що не є монадичним в haskell), може бути вичислено заздалегідь компілятором, але такі обчислення можуть бути дорогими, і тому, ймовірно, робляться лише частково.

Крім того, все, що не потрібно обчислювально, можна повністю оптимізувати з програми.

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

Більш цікавим є те, чи реально вони реалізовані в поточних компіляторах і наскільки ці оптимізації є на практиці (тобто остаточне виконання ідіоматичного коду «реального життя») у виробничому середовищі з апріорними передбачуваними налаштуваннями компілятора).

наприклад, подання Haskell для сумнозвісної гри на комп'ютерній мові Benchmark (як це погано, але це не так, як є - на даний момент - щось набагато краще там) створюють враження, що на це витрачено значну кількість часу ручні оптимізації, які стикаються з твердженням про "можливі оптимізації компілятора завдяки insert some property about FP languages here", виглядають так, що оптимізації є (наразі принаймні) більш теоретичними можливостями, ніж відповідною реальністю.

Я був би радий, хоча в цьому питанні я виявився неправильним.

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

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

Зараз є два застереження:

• Спільнота мов програмування протягом останніх п'ятдесяти років витратила багато зусиль на розробку розумних способів цього аналізу. Існують відомі хитрощі, такі як забарвлення реєстру тощо, щоб зробити більш прості випадки більшу частину часу; але це робить великими, повільними компіляторами та постійним компромісом складності компіляції для якості отриманого коду
• У той же час більшість функціональних мов програмування також не є суто функціональними; багато речей, які насправді потрібно робити програмам, як-от відповідь на введення-виведення, за своєю суттю нефункціональні, тому жоден компілятор не може бути абсолютно вільним від цих хитрощів, і жодна мова не уникає їх цілком - навіть Haskell, що теж трохи чисто на мій смак (Ваша пробіг може змінюватись) може лише контролювати та відключати нефункціональні частини вашого коду, а не уникати їх взагалі.

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