mtl、トランスフォーマー、モナド-fd、monadLib、および選択のパラドックス
Hackageには、モナド変換子用のパッケージがいくつかあります。
- mtl ：モナド変換子ライブラリ
- トランスフォーマー ：コンクリートファンクターとモナドトランスフォーマー
- monads-fd ：関数従属性を使用したモナドクラス
- monads-tf ：型族を使用したモナドクラス
- monadLib ：モナド変換子のコレクション。
- mtl-tf ：型族を使用したモナド変換子ライブラリ。
- mmtl ：モジュラーモナド変換子ライブラリ
- mtlx ：タイプインデックスを備えたモナド変換子ライブラリ。「無料」のコピーを提供します。
- compose-trans ：構成可能なモナド変換子
（そして多分私はいくつかを逃した）
どちらを使用しますか？
mtlはHaskellプラットフォームのものですが、私はredditでそれがクールではないと聞いています。
しかし、とにかく選択の何が悪いのか、それはただ良いことではありませんか？
たとえば、データアクセサの作成者は、人気のある選択肢だけに対応するために、これらすべてを作成する必要があることを知りました。
- data-accessor-monadLibライブラリ：monadLibのモナドのアクセサ関数
- data-accessor-monads-fdライブラリ：Accessorを使用してmonads-fd状態monadクラスの状態にアクセスします
- data-accessor-monads-tfライブラリ：Accessorを使用してmonads-tf状態モナドタイプファミリの状態にアクセスします
- data-accessor-mtlライブラリ：Accessorを使用してmtl Statemonadクラスの状態にアクセスします
- data-accessor-transformersライブラリ：Accessorを使用してトランスフォーマーの状態にアクセスしますState monad
これが続き、たとえばいくつかの競合するArrowパッケージが進化すると、spoonklink-arrows-transformers、spoonklink-arrows-monadLib、spoonklink-tfArrows-transformers、spoonklink-tfArrows-monadLib、...
そして、spoonklinkがフォークされると、Hackageのディスク容量が不足するのではないかと心配しています。 :)
質問：
- なぜこれほど多くのモナド変換子パッケージがあるのですか？
- Mtl [考慮]がクールでないのはなぜですか？
- 主な違いは何ですか？
- これらの一見競合するパッケージのほとんどは、Andy Gillによって作成され、RossPatersonによって保守されています。これは、これらのパッケージが競合しておらず、何らかの方法で連携していることを意味しますか？そして、AndyとRossは、自分たちのパッケージのいずれかを廃止したと見なしますか？
- あなたと私はどちらを使うべきですか？
それらの束はほぼ完全に同等です：
mtlはGHC拡張機能を使用しますが、transformersはHaskell98です。monads-fdとmonads-tfは、それぞれ機能従属性と型族を使用するtransformersのアドオンであり、どちらもmtlにない機能をtransformersに提供します。 _。mtl-tfはmtl型族を使用して再実装されています。
つまり、本質的には、mtl == transformers ++ monads-fd、mtl-tf == transformers ++ monads-tfです。 transformersとそれに関連するパッケージの移植性とモジュール性の向上が、最近mtlがクールではない理由だと思います。
mmtlとmtlxはどちらもmtlに類似しているか、それに基づいているようですが、APIの違いと追加機能があります。
MonadLibは問題についてかなり異なる見方をしているようですが、私はそれを直接は知りません。また、他の拡張機能よりも多くのGHC拡張機能を使用しているようです。
一見すると、compose-transは、モナド変換子を作成するためのメタプログラミングのようなもののようです。 Control.Monad.Transと互換性があると主張しています...これはmtlを意味すると思いますか？
とにかく、私は次の決定アルゴリズムを提案します：
- 新しいプロジェクトに標準のモナドが必要ですか？
transformers＆co。を使用して、mtlを休ませてください。 - 大規模なプロジェクトですでに
mtlを使用していますか？transformersは完全に互換性があるわけではありませんが、切り替えを行わなかったために誰もあなたを殺すことはありません。 - 他のパッケージの1つは、必要な異常な機能を提供しますか？あなた自身を転がすよりもそれを使うほうがよいでしょう。
- まだ満足していませんか？それらをすべて捨て、ダウンロード
category-extras、そして1ページ半で世界のすべての問題を解決します理解できない抽象的なナンセンス息を呑むほど一般的なコード。
今のところは？おそらくmtlを使用する必要があります。何が起こっているのかというと、transformersライブラリはmonads-fdとmonads-tfが平和的に共存できるように、MTLから除外されていますが、最後に確認しましたが、まだそうではありませんでした。
その場合、monads-fdとtransformersをインポートして、StateなどがStateTのエイリアスになることを除いて、（ほぼ）同じインターフェイスを取得できます。
したがって、私はmtlに書き込みますが、State、Readerなどがdatasに置き換えられるため、現在typeであるという事実に依存しません。
MonadLibは、Iavorが取り組んできたもう1つの代替手段であり、モジュール名を他のユーザーと共有しないため安全に使用できますが、使用パターンはかなり異なります。
彼の答え で言及されているEdward Kmettの因数分解は、2010年後半に完了しました。その最終結果はmonads-fdであり、 トランスフォーマー、mtlのバージョン2になります。 mtl、monads-tfの遍在性の結果として、実際には決して引っかかった。 2017年の初めの時点で、mtlとトランスフォーマーが唯一のモナドトランスフォーマーライブラリです広く使用されています。