Add composition of MonadTransformers

[sjshuck]

[original issue 84 by @Icelandjack]

Add

--      ComposeT :: MonadTransformer -> MonadTransformer -> MonadTransformer
type    ComposeT :: (k3 -> k2 -> Type) -> (k1 -> k3) -> (k1 -> k2 -> Type)
newtype ComposeT trans1 trans2 m a = ComposeT (trans1 (trans2 m) a)
  deriving newtype (Functor, Applicative, Monad)

instance (MonadTrans trans1, MonadTrans trans2) => MonadTrans (ComposeT trans1 trans2) where
  lift :: Monad m => m ~> ComposeT trans1 trans2 m
  lift = ComposeT . lift . lift

where MonadTransformer = (Type -> Type) -> (Type -> Type).

Now we can derive MonadTrans for transformers like

type    OkT :: MonadTransformer
newtype OkT m a = OkT (Int -> Int -> m a)
 deriving (Functor, Applicative, Monad)
 via ReaderT Int (ReaderT Int m)

 deriving MonadTrans
 via ComposeT (ReaderT Int) (ReaderT Int)

[sjshuck]

[original comment by @Icelandjack]

https://hackage.haskell.org/package/mmorph-1.2.0/docs/Control-Monad-Trans-Compose.html

[L0neGamer]

While we're at it, do we want our own version of MFunctor? We could use prior art of MonadTransHoist from monadology

[L0neGamer]

We would also want to add all the mtl instances once this goes live, and then possibly patch mmorph to just re-export our variant.

[sjshuck]

I think mmorph's scope is well-defined and this falls within that. ComposeT in particular I do think belongs here, but the main value it adds can be expressed in terms of typeclasses that already exist here.

I get that there are a bunch of specialized mapBlahT functions, and it's beautiful to abstract them, but it doesn't really add any utility for transformers users IMO—if they really want that, they can import mmorph.

[L0neGamer]

I do think there is utility for ComposeT to define mtl classes, so that one can still use your reader and state effects even if your transformer is wrapped up in ComposeT.

To reduce on overlap across the ecosystem, it would be a good idea to solidify on one version of a type, and that means we need to offer the same interface.

I feel less strongly about a potential transformers:MonadTransHoist; I think it obviously has value here but MMonad feels like a step too far, and so leaving them with mmorph is fine. Should we link to mmorph and mention it for these purposes?

[sjshuck]

mtl classes

100% agree.

one version

Sorry, what were the two versions of the same type in question?

link to mmorph

Absolutely.

[L0neGamer]

There's a ComposeT in mmorph as well