Чому функціональні мови програмування вимагають збирання сміття?

Що зупиняє ghc від перекладу Haskell в конкатенативну мову програмування, таку як комбінаційна логіка, а потім просто використання розподілу стеків для всього? Згідно з Вікіпедією, переклад з обчислення лямбда в комбінаторну логіку є тривіальним, а також, конкатенативні мови програмування можуть покладатися виключно на стек для розподілу пам'яті. Чи можливо зробити цей переклад і таким чином виключити збирання сміття для таких мов, як Haskell та ocaml? Чи є в цьому недоліки?

EDIT: переміщено сюди /programming/39440412/why-do-functional-programming-languages-require-garbage-collection

Усі наступні коментарі ґрунтуються на виборі стандартної стратегії впровадження, використовуючи закриття для представлення значень функцій та порядку оцінки за закликом за значенням:

1. Для чистого обчислення лямбда збирання сміття не потрібно. Це тому, що неможливо формувати цикли в купі: кожне новопризначене значення може містити лише посилання на раніше виділені значення, і тому графік пам'яті утворює DAG - тому підрахунок посилань достатній для управління пам'яттю.

2. Більшість реалізацій не використовують підрахунок посилань з двох причин.

   1. Вони підтримують форму типу вказівника (наприклад, refконструктор типу в ML), і тому можна сформувати справжні цикли в купі.
   2. Довідковий підрахунок набагато менш ефективний, ніж вивезення сміття
      • йому потрібно багато додаткового простору для збереження відліків та
      • оновлення підрахунків зазвичай є марною роботою, і
      • оновлення підрахунків створюють купу суперечок щодо запису, що вбиває паралельну продуктивність.

3. Лінійно-введені мови можуть усунути кількість посилань (фактично тому, що підрахунки дорівнюють 0-1: або значення має єдине посилання на нього, або воно мертве і може бути звільнене).

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

5. Ви можете отримати правильну асимптотику, замінивши стек на "стек спагетті" (тобто реалізуйте стек як пов'язаний список у купі, щоб ви могли вирізати мертві кадри за необхідності).

6. Якщо ви хочете реальної дисципліни стека, ви можете використовувати системи типів на основі "впорядкованої логіки" (по суті лінійних типів мінус обмін).