私は朝と午後の大部分を Haskell の GUI フレームワークで遊んでいました。視覚化と対話機能が必要であり、Haskell でコア機能を記述してフロントエンドにパイプアウトするのが好きではないためです。別の GUI で。すべてを 1 つの言語から行うことをお勧めします。その大部分は、ソース コードのコンパイルとパッチの適用、またはあいまいなコンパイル エラーのグーグル検索に費やされています。
SO の質問を読んだり、haskell.org を読んだり、ドキュメントを読んだりするのに多くの時間を費やしました。私が遭遇したのは、時代遅れの情報や文書化されていない情報が非常に大量にあることです。この3つに要約できます。
Gtk+ バインディングの上に構築された多数のオプション。私は Gtk+ をあまり気にしません。特に OS X では、Gtk+ を見るのが非常に不快であることが主な理由です。自分。特に、私が作成したプログラムを他の人に利用してもらいたい場合。
wxHaskell は安定しており、非常に簡単にインストールできますが、既存のチュートリアルの多くは wx-0.1x 用のようであり、wxWidgets 2.9.x ドキュメントを wx-0.90.x にブリッジするための規則は非常にむらがあり、理解するのが困難です。それらが存在する場合でも。
ほとんど放棄されているように見えるqtHaskell（間違っていたら訂正してください）は、1年前のパッチを適用した後にGHCの新しいバージョンでのみコンパイルし、すぐにコンパイルエラーになることを示す大量の警告を吐き出します. GHCの新しいバージョン。
実際、私は Java の Swing に対する Haskell の回答を探しています。堅牢で、保守され、十分に文書化されており、使い始めるのが簡単で、ルック アンド フィールをネイティブにしようと試み、GHC の開発ペースについていくことができ、放棄されるリスクが高くないライブラリです。これはまさにゼロの GUI フレームワークのようですが、GUI フレームワークに関連する「公式」リソース/ウィキ/ページ/ドキュメントのほとんどはひどくメンテナンスされていないようです。見つかりませんでした。OS X の最新バージョンで動作する限り、フレームワークがクロス プラットフォームであることをあまり心配していません。
繰り返しますが、haskell.org や WikiBook へのリンクを送ってくれる人を探しているわけではありません。私はそこに行ったことがありますが、見たものが好きではありませんでした。そこにある情報のほとんどはあまりにも古くなっているため、作業が増えるだけで、減ることはありません。
特に Haskell のような小さなコミュニティを持つ言語の場合、私の「要求」は少し極端であることに気づきましたが、誰かが私を助けてくれることを望んでいました. 当面は、成功するか死ぬまで、wxHaskell や qtHaskell を乗り切るつもりです。
私が不機嫌そうに見えたり、疲れ果てていたりしないことを願っています。