concrete functor and monad transformers
#48Monoid instance for ReaderT
This has been requested before, but I would like to propose it again:
instance (Monoid a, Applicative m) => Monoid (ReaderT e m a) where ...- Previous issue: https://hub.darcs.net/ross/transformers/issue/38
- Recent Mailing List Discussion: https://mail.haskell.org/pipermail/libraries/2017-November/028312.html
- Old Mailing List Discussion: https://mail.haskell.org/pipermail/haskell-cafe/2017-March/126588.html
- Reddit Discussion (tangential): https://www.reddit.com/r/haskell/comments/7vfhvl/the_wizard_monoid/
This proposal enjoys broad support. The only objection made is that ReaderT could instead be given a Monoid instance that has identical behavior to its Alternative instance. However, this behavior (by definition) is already provided by the Alternative instead, and no one involved in any of the above discussions actually wanted to use a Monoid instance for ReaderT that was defined this way. I would like the transformers maintainer to make an executive decision on this to settle the issue. Thanks.
It seems that the same issue applies to all the transformers: there are two possible Monoid instances, one matching Alternative and the other lifted through Applicative. (In some cases, like MaybeT, there are more.) It's been argued that one of these is already available as Alternative, but the real issue is which one can be used with Monoid interfaces. I still think that the principle of not defining an instance unless there is a canonical choice is sound, so I think it would be better to use adaptor newtypes, of which Alt is already available. If you can't get the other newtype into base, it could be defined here.
This reasoning strikes me as insufficiently motivated. More, it is actually not consistent with the Haskell community which has provided a Monoid instance for IO via
Ap-style semantics.
