関数型プログラミング言語には、コンパイル時の最適化を行う機会がありますか？

私は「実世界のための関数型プログラミング」という本を読んでいました。まず、命令型プログラミング言語と関数型プログラミング言語の比較から始めました。そして、関数型プログラミングの「値」と「式」が命令型プログラミングの「変数」と「関数」とどのように異なるかを述べました。ディスカッションから私は次のようなアイデアを開発しました-

関数型プログラミング言語には、対応する命令型言語よりもコンパイル時間の最適化を行う機会が多くあります。

本当ですか？

関数型プログラミング言語は、コンパイル時の最適化をはるかに上回ります。理由の1つは、純粋さです。状態がないため、同時実行は簡単です。そのため、コンパイラは2つの分岐を取り、プログラムの動作を変更せずにそれらを簡単に一致させることができます。

同時に、状態なしで計算できるもの（つまり、Haskellでモナドでないもの）は、コンパイラによって事前に計算できますが、そのような計算はコストがかかる可能性があるため、おそらく部分的にしか行われません。

さらに、計算に不要なものはすべて、プログラムから完全に最適化できます。

原則として、関数型言語には、対応する命令型のものよりもコンパイル時の最適化の可能性が高いというのは、おそらく本当です。

しかし、より興味深いのは、それらが現在のコンパイラーに実際に実装されており、これらの最適化が実際にどの程度関連しているか（つまり、演繹的な予測可能なコンパイラー設定での本番環境における慣用の「real life（TM）」コードの最終パフォーマンス）です。

たとえば、悪名高いコンピューター言語ベンチマークゲームのHaskellへの提出（悪いかもしれませんが、現時点ではそれほど優れていません）は、かなりの時間が費やされたように見えます手動による最適化は、「原因によるコンパイラの最適化の可能性」に関する主張に直面してinsert some property about FP languages here、最適化は関連する現実よりも（現在は少なくとも）理論的な可能性のように見えます。

私はこの点で間違っていると証明されて嬉しいです。

関数型では、プログラムを介した値のフローは非常に非常にわかりやすくなっています（コンパイラとプログラマの両方にとって）。これにより、コンパイラは、値を格納する場所、値を保持する期間などを決定する余裕が大幅に広がります。

命令型言語では、コンパイラーは、ほとんどの変数が定義された存続期間中存続するメモリー内の実際の位置に対応するモデルをプログラマーに約束します。潜在的に、ステートメントはこれらの場所のいずれかから読み取り（または書き込み！）する可能性があるため、コンパイラーはメモリーの場所をレジスター割り当てで置き換えるか、2つの変数を単一のストレージ場所にマージするか、または場所の入念な分析を実行した後に同様の最適化を実行できますプログラム内では、その変数が参照される可能性があります。

ここで、2つの警告があります。

• プログラミング言語コミュニティは、過去50年間、この分析を行うための巧妙な方法の開発に多くの努力を費やしました（無駄にしたのですか？）。ほとんどの場合、簡単なケースのいくつかを実行するために、レジスターカラーリングなどのよく知られたトリックがあります。しかし、これは大きくて遅いコンパイラと、コンパイルの複雑さと結果のコードの品質との一定のトレードオフをもたらします
• 同時に、ほとんどの関数型プログラミング言語も純粋に関数型ではありません。何のコンパイラはこれらのトリックの完全に自由になることはできませんので、実際にI / Oに応えるように、行うために必要なもののプログラムの多くは、本質的に非機能的であり、何の言語はそれらを完全に回避できない-ビットであってもHaskellの、あまりにもを純粋に私の好みに合わせて（Your Mileage May Vary）は、コードの非機能部分のみを制御およびウォールオフでき、完全に回避することはできません。

しかし、一般的な質問に答えるために、はい、機能的パラダイムはコンパイラーを命令的な設定にはない最適化する多くの自由を与えます。