関数型プログラミング言語にガベージコレクションが必要なのはなぜですか？

ghcがHaskellを組み合わせロジックなどの連結プログラミング言語に翻訳し、単純にすべてにスタック割り当てを使用するのを妨げているのは何ですか？ウィキペディアによると、ラムダ計算から組み合わせロジックへの翻訳は簡単であり、また、連結プログラミング言語はメモリ割り当てのためにスタックのみに依存することができます。この翻訳を実行して、Haskellやocamlなどの言語のガベージコレクションを削除することは可能ですか？これを行うには欠点がありますか？

編集：ここに移動/programming/39440412/why-do-functional-programming-languages-require-garbage-collection

以下のコメントはすべて、クロージャーを使用して関数値と値ごとの評価の順序を表す標準的な実装戦略の選択を前提としています。

1. 純粋なラムダ計算では、ガベージコレクションは不要です。これは、ヒープ内でサイクルを形成することができないためです。新しく割り当てられたすべての値には、以前に割り当てられた値への参照のみを含めることができるため、メモリグラフはDAGを形成するため、メモリを管理するには参照カウントで十分です。

2. ほとんどの実装では、2つの理由で参照カウントを使用しません。

   1. ポインタ型（refML の型コンストラクタなど）の形式をサポートしているため、ヒープ内の真のサイクルを形成できます。
   2. 参照カウントはガベージコレクションよりもはるかに効率が悪いため、
      • 参照カウントを保持するために多くの追加スペースが必要です。
      • 通常、カウントの更新は無駄な作業です。
      • カウントの更新により、多数の書き込み競合が発生し、並列パフォーマンスが低下します。

3. 線形型言語では、参照カウントを削除できます（基本的にカウントが0〜1であるため、値は単一の参照を持っているか、無効であり、解放できます）。

4. ただし、スタックの割り当てではまだ十分ではありません。これは、自由変数を参照する関数値を形成することが可能であるため（つまり、関数クロージャを実装する必要があります）、スタックに物を割り当てると、ライブ値がデッド値でインターリーブされる可能性があり、これにより不正な漸近が発生しますスペース使用量。

5. スタックを「スパゲッティスタック」に置き換えることで適切な漸近性を得ることができます（つまり、スタックをリンクリストとしてヒープに実装し、必要に応じてデッドフレームを切り取ることができます）。

6. 実際のスタック制御が必要な場合は、「順序付けされたロジック」に基づく型システムを使用できます（本質的に線形型から交換を差し引いたもの）。