コンパイラを関数型言語で書く方が簡単なのはなぜですか？[閉まっている]

私はこの質問について長い間考えていましたが、Googleでの答えもStackoverflowでの同様の質問も実際には見つかりませんでした。重複している場合は、ごめんなさい。

多くの人は、OCamlやHaskellなどの関数型言語でコンパイラやその他の言語ツールを書く方が、命令型言語で書くよりもはるかに効率的で簡単だと言っているようです。

これは本当ですか？そして、もしそうなら、なぜCのような命令型言語ではなく関数型言語で書くのが、なぜそんなに効率的で簡単なのでしょうか？また、関数型言語の言語ツールは、Cのような低水準言語よりも遅くありませんか？

多くの場合、コンパイラーはツリーを多く使用します。ソースコードが構文ツリーに解析されます。次に、そのツリーは、タイプチェックを実行するためにタイプアノテーションを持つ別のツリーに変換されます。次に、そのツリーをコア言語要素のみを含むツリーに変換します（構文的な砂糖のような表記を砂糖を含まない形式に変換します）。これで、基本的にツリーの変換であるさまざまな最適化を実行できます。その後、通常の形式でツリーを作成し、そのツリーを反復処理してターゲット（アセンブリ）コードを作成します。

関数型言語には、パターンマッチングや効率的な再帰のサポートなどの機能があり、ツリーを簡単に操作できるため、コンパイラを書くのに一般的に優れた言語と見なされています。

多くのコンパイラタスクは、ツリー構造でのパターンマッチングです。

OCamlとHaskellはどちらも、強力で簡潔なパターンマッチング機能を備えています。

パターンを照合するために評価または抽出される値には副作用がないため、命令型言語にパターンマッチングを追加することは困難です。

考慮すべき重要な要素の1つは、コンパイラプロジェクトの大部分は、コンパイラをセルフホストして「自分のドッグフードを食べる」ことができることです。このため、言語研究用に設計されたOCamlなどの言語を見ると、コンパイラタイプの問題に優れた機能を備えている傾向があります。

私の最後のコンパイラー風のジョブでは、Cコードを操作する際にまさにこの理由でOCamlを使用しました。これは、タスクに最適なツールでした。INRIAの人々がさまざまな優先順位でOCamlを構築していたとしたら、それほど適切ではなかったかもしれません。

とはいえ、関数型言語はあらゆる問題を解決するための最良のツールであるため、論理的には、この特定の問題を解決するための最良のツールであると言えます。QED。

/ me：Javaタスクにクロールバックして少し楽しくない...

基本的に、コンパイラーは、あるコードセットから別のコードセットへの変換です。ソースからIR、IRから最適化されたIR、IRからアセンブリーなどです。これは、関数型言語が設計されたものとまったく同じです。純粋な関数はあるものから別のものへの単なる変化。命令型関数にはこの品質はありません。この種のコードは命令型言語で記述できますが、関数型言語はこの言語に特化しています。

こちらもご覧ください

F＃デザインパターン

FPは「操作」で物事をグループ化しますが、OOは「タイプ」で物事をグループ化します。コンパイラー/インタープリターにとっては「操作による」の方が自然です。

1つの可能性は、コンパイラーが多数のコーナーケース全体を非常に注意深く処理しなければならない傾向があることです。多くの場合、コードを正しく理解するには、実装するルールに対応する方法で実装を構造化するデザインパターンを使用する方が簡単です。多くの場合、これは命令型（シーケンス、「いつ」）の設計ではなく、宣言型（パターンマッチング、「どこ」）になるため、宣言型言語で実装するのが簡単です（そのほとんどは機能的です）。

誰もが別の重要な理由を見逃したようです。通常のコードの（E）BNFによく似たパーサー用の組み込みドメイン固有言語（EDSL）を書くのは非常に簡単です。Parsecのようなパーサーコンビネーターは、高階関数と関数構成を使用して、関数型言語で非常に簡単に記述できます。簡単なだけでなく、非常にエレガントです。

基本的に、最も単純な汎用パーサーを単なる関数として表し、これらのプリミティブパーサーを文法用のより複雑でより具体的なパーサーに構成できるようにする特別な操作（通常は高次関数）を使用します。

これはコースの枠組みをパーラーする唯一の方法ではありません。