デフォルトで遅延評価ではなく厳密評価を使用する Haskell コンパイラを探しています。私は OCaml を使用するだけですが、Haskell の構文はOCaml よりもはるかに優れています(Haskell は純粋で、型クラスなどの優れた機能を備えています)。
プログラム全体に常に!s とsを入れたくないのです。$!厳密さの注釈を入れるためのスイッチまたはプリプロセッサを備えたコンパイラは本当に素晴らしいでしょう。また、無限リストのようなものが必要な場合に備えて、特定の場所でも遅延評価を使用する方法があれば役立ちます (おそらく決してそうしません)。
遅延評価の方が優れていると私に納得させようとしないでください。私は本当にパフォーマンスが必要です。IIRC の Simon Peyton Jones は、遅延評価は実際には必要ではなく、主に言語が不純になるのを防ぐためにあるとさえ述べています。
厳密な評価を使用するHaskellコンパイラを使用している場合、Haskellはコンパイルされません。怠惰非厳密性はHaskell仕様の一部です！
ただし、代替手段があります。
DDCは、Haskellの残りのすべての長所を保持しながら、破壊的な更新などをサポートするHaskellの明示的に怠惰なバリアントを作成する試みです。1つの問題があります。コンパイラは現在、少なくとも使用可能であるように見えますが、αステージにしかありません。
Haskellの「正しい方法」の使い方を学びましょう。テストケースを公開できるものに単純化できる場合は、Haskell-Caféメーリングリストに投稿することができます。このメーリングリストでは、非厳密性の影響に関するこの種の質問に非常に役立ちます。
過去に Haskell を厳密に評価するための 2 つの試みがありました。
しかし、どちらも Haskell の非厳密なセマンティクスに固執することに重点を置いていましたが、実際にセマンティクスを変更するのではなく、ほぼ厳密な評価戦略を使用しており、実際に日の目を見ることはありませんでした。
編集：Martijnのstrict-pluginの提案は、実際にあなたが望むことを行い、著者はまだHaskellコミュニティで活動しているため、あなたの目的に理想的です.私はそれを忘れていました.
Monad Reader 12で説明されている、GHCのプラグインフレームワークの例であるghc-strict-pluginも参照してください。
あなたの痛みが分かります。日々のプログラミングにおける最大の PITA は、これらの !@#$%^&( スペース リークに対処することです。
ただし、それが役立つ場合は、時間の経過とともに、これに対処する方法を (難しい方法で) 学習し、改善されます。しかし、Andy Gill が彼の魔法のスペース リーク プロファイラーで私のすべての問題を解決してくれるのを待っています。(前回の ICFP で、彼がこのクールなアイデアを思いついたのは、それを実装するという約束だったという彼の率直なコメントを私は受け取っています。)
遅延評価が世界で最も優れていると説得するつもりはありませんが、遅延評価にはいくつかの良い点があります。私は、3.5 MB ほどのメモリ (そのうち 2MB 以上は GHC ランタイム) しか使用せずに、ギガバイトのデータを問題なく実行するさまざまなコンビネータを介して遅延リストをスクーティングするストリーム処理プログラムをいくつか持っています。そして、昨年、私よりも賢い人が、典型的な Haskell プログラマーとして、どれだけ遅延評価に依存しているかに本当に驚くだろうと指摘しました。
しかし、私たちが本当に必要としているのは、現実の世界での遅延評価を扱うための本当に優れた本です (学問の世界とそれほど違いはありませんが、単に論文が発表されないことと、クライアントが私たちの後に来ることを除いて)これは、これに関連するほとんどの問題を適切にカバーし、さらに重要なことに、何がヒープを爆発させ、何がそうでないかを直感的に理解できるようにします。
これは新しいことではないと思います。他の言語やアーキテクチャもこれを経験したと確信しています。結局のところ、最初のプログラマーはハードウェア スタックなどをどのように扱ったのでしょうか? よくないね、きっと。
私は最近、この分野でいくつかの作品を見ました:
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
これについては、SPJ の GHC ステータス更新で少し聞くことができます。
http://youtu.be/Ex79K4lvJno?t=9m33s (9:33の該当作品からリンク開始)
どこでも nfdata と rnf を使用することは、既に評価された大きな構造を繰り返し横断することを意味するため、解決策ではありません。
Ben Lippmeier の博士論文 (DDC について) の導入部の章は、私が見た中で最高の Haskell 批判についてのものです。遅延、破壊的更新、モナド変換などの問題について説明しています。DDC には遅延がありますが、明示的に要求する必要があります。であり、DDC のタイプと効果のシステムによって追跡および管理される効果と見なされます。
lazy-strict スペクトルの中間を目指すseqaidもあります。
Seqaid は、Haskell プロジェクトの非侵襲的な自動インスツルメンテーションを提供する GHC プラグインで、厳密性 (および並列処理) を動的に制御します。これには、最小限の厳密化を使用した自動スペース リーク リリーフの最適化が間もなく含まれます。
あなたは厳密な評価の価値についてははっきりと決心しましたが、Haskell を使用するポイントを見逃していると思います。Haskell の遅延評価により、コンパイラ/インタプリタが採用するより柔軟な最適化戦略が可能になります。独自の厳密性を強制すると、オプティマイザーがオーバーライドされます。結局、過度に厳密な評価を使用しても、自動最適化ほど効率的ではありません。遅延評価を使用して、または遅延評価を使用せずに、GHCI の一連の数値の折り畳み合計を試してください。違いがはっきりとわかります。この場合、遅延評価の方が常に高速です。