FreeT / ProgramT によって作成されたモナド変換子の mtl のようなメカニズムはありますか?
私の歴史認識は以下の通りです。むかしむかし、モナド変換子が発明されました。その後、人々はモナド変換子を積み重ねるようになり、lift
どこにでも挿入するのが煩わしいことに気づきました。その後、ask :: m r
何人かの人々がモナドクラスを発明しましm
たMonadReader r m
。これは、すべてのモナドクラスがすべてのモナドトランスフォーマーを貫通するようにすることで可能になりました。
(Monoid w, MonadState s m) => MonadState s (WriterT w m)
MonadWriter w m => MonadWriter w (StateT s m)
モナド変換子のペアごとにこのようなインスタンス宣言のペアが必要なので、モナド変換子がn 個ある場合、 n ^2 のコストがかかります。しかし、これは大きな問題ではありませんでした。人々はほとんどの場合、定義済みのモナドを使用し、独自のモナドを作成することはめったにないからです。これまでの話は私が理解しており、次の Q&A などで詳しく説明しています。
次に、私の問題は、新しい Free モナドhttp://hackage.haskell.org/package/freeと Operational モナドhttp://hackage.haskell.org/package/operationalにあります。代数型として言語を定義するだけで、独自の DSL を記述してモナドとして使用できます(Operational はインスタンスdata
さえ必要としません)。Functor
良いニュースは、モナドとモナド変換子を無料で持てるということです。ではモナドクラスはどうだろうか?悪いニュースは、「独自のモナド変換子を定義することはめったにない」という仮定がもはや成り立たなくなったことです。
この問題を理解しようとして、2 つProgramT
の を作成し、それらを互いに貫通させました。
https://github.com/nushio3/practice/blob/master/operational/exe-src/test-05.hs
このoperational
パッケージはモナド クラスをサポートしていないため、別の実装minioperational
を使用して、必要に応じて動作するように変更しました。https://github.com/nushio3/minioperational
それでも、特殊なインスタンス宣言が必要でした
instance (Monad m, Operational ILang m) => Operational ILang (ProgramT SLang m) where
次の形式の一般的な宣言は、決定不能なインスタンスにつながるためです。
instance (Monad m, Operational f m) => Operational f (ProgramT g m) where
私の質問は、どうすれば Operational モナドが互いに浸透しやすくなるかということです。または、不適切なポーズの操作モナドを貫通したいという私の願いです。
また、侵入の正しい専門用語も知りたいです:)