したがって、純粋な関数型言語には、純粋なコードと不純なコードが明確に分離されているため、独自のクラスの可能性があります。Nested DataParallelismやStreamFusionのように、Haskellで実装するのがいくらか簡単な機能をいくつか見てきました。
私の質問は、実現可能性/シンプルさの点でHaskellに多かれ少なかれユニークであるが、まだ実装されていない他の改善/最適化は何ですか?(私は主にGHCに関心がありますが、他の人のことも聞くのが大好きです)
したがって、純粋な関数型言語には、純粋なコードと不純なコードが明確に分離されているため、独自のクラスの可能性があります。Nested DataParallelismやStreamFusionのように、Haskellで実装するのがいくらか簡単な機能をいくつか見てきました。
私の質問は、実現可能性/シンプルさの点でHaskellに多かれ少なかれユニークであるが、まだ実装されていない他の改善/最適化は何ですか?(私は主にGHCに関心がありますが、他の人のことも聞くのが大好きです)
GHCで見たい最適化の1つは、スーパーコンパイルです。ただし、GHCはプログラム全体の最適化であり、GHCはモジュールごとのコンパイルに非常に重点を置いているため、これはGHCの近い将来には起こりそうにありません。
基本的に、スーパーコンパイルはコンパイル時にできるだけ多くのプログラムを実行します。それは当然、インライン化、森林伐採、特殊化、および他の多くの技術を包含します。初期の実験結果は有望でしたが、それは非常に費用のかかるプロセスです。それが実用的な最適化であるとは思えませんが、コンセプトは途方もなく素晴らしいです。
SPJがモジュラースーパーコンパイルに関する彼の論文で述べているもう1つの問題は、スーパーコンパイルとアンボクシングの組み合わせです。スーパーコンパイルされたプログラムでの開封の可能性は大幅に減少します。これにより、GHC strict-analyser/unboxerを通過する最適化されていないプログラムと比較してパフォーマンスが低下します。http://research.microsoft.com/en-us/um/people/simonpj/papers/supercompilation/を参照してください
もう1つの強力であるが、「まだ本番環境で使用する準備ができていない」手法は、ワーカーラッパー変換です。