ErrorTモナドにエラーメッセージを蓄積することは可能ですか？私は1つ多くのエラーを蓄積したいと思います。これは、いずれかが存在する場合、エラーのリストを返す、または成功した結果ErrorTを使用してエラーを累積する
ghci> import Control.Applicative
ghci> import Control.Applicative.Lift
ghci> failure ['a'] *> pure() <* failure ['b']
Other (Constant "ab")
：
あなたは変圧からControl.Applicative.LiftからErrorsのApplicativeを使用することができます。
このタイプは、通常、「検証」アプリケーションとして知られています。 Hackageにはother implementationsがあります。可能な改善の1つは、障害容器の要件をMonoidに緩和し、Semigroupも可能にすることです。
ErrorsタイプがMonadではないことに注意してください。しかし、他のApplicativeと組み合わせることができますData.Functor.Composeを使用しています。 ExceptTため
MonadPlusインスタンスが関連しているが同一ではない振る舞いがあります。それは、いずれかが存在する場合、最初の成功を返すか、エラーのリスト：
ghci> throwE ['a'] `mplus` return() `mplus` throwE ['b'] :: ExceptT [Char] Identity()
ExceptT (Identity (Right()))
ghci> throwE ['a'] `mplus` throwE ['b'] :: ExceptT [Char] Identity()
ExceptT (Identity (Left "ab"))
'Either' /' ExceptT'/'ErrorT'は本質的に短絡するように設計されているので、答えは「いいえ」です。しかし、複数のエラーを累積したい場合は、別のモナド/モナド変換器を使うべきです（この場合はおそらく 'WriterT'です）。 –
ErrorTをWriterTに置き換えるのは難しいですか？現時点で私は "モナド（StateT、ErrorT、IO）のタワー： –
を持っています。機械的に難しいという意味では難しいことはありませんが、' ErrorT'と 'WriterT'は非常に異なるセマンティクスを持っています。 'ErrorT'の全体的なポイントは、計算が失敗することができるということです。複数のエラーを累積したい場合、それはおそらく計算を続けることを意味します。あなたのコードにどのような影響があるか考えてください。エラーの場合は 'WriterT'と' ExceptT'（ 'ErrorT'は途中で廃止され、代わりに' ExceptT'を使用してください）が混在している必要があります。 –