Manuel Bärenz

I'd argue against this on a package level. The dependency argument is a very heavy one. But also architecturally, I believe it's not ideal to pin down dunai as the...

> My main incentive for merging the repos is that I'd then feel slightly happier using the current docs template in monad-bayes to add docs for dunai-bayes (since it would...

It seems to me that using `ApplicativeDo` is mainly something a library user can do. All the newtypes derive `Applicative`, so their instances will be used. Other than that it...

Inconclusive. Some benchmarks get faster, some slower. There is no big improvement on either side. So I guess it's a harmless change to enable it by default, but it doesn't...

> The [paper](http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/applicativedo.pdf) introducing it actually mentions specifically that monad-bayes could benefit from this extension. @adscib I can't find that claim. Can you point me to it? Maybe we're forcing...

I think the closest to this is the already existing `MonadBase`: https://hackage.haskell.org/package/transformers-base/docs/Control-Monad-Base.html#t:MonadBase

How does your `instance MMonad SeqT` avoid having a `Monad n` constraint? You're using `>>=` in `step`, for example, but `Monad (SeqT n)` requires `Monad n`.

There is a similar issue about `ProgramT`, which uses a view function which needs a `Monad` constraint: https://github.com/Gabriel439/Haskell-MMorph-Library/issues/11#issuecomment-847125948 But if you dig down into the definition of `ProgramT`, you can...

Ohh, thanks for the clarification. Yes, this is quite confusing. Regarding your original question, I sometimes use transformers as `Applicative` transformers, and there I usually don't expect the natural transformations...

But the change in `hoist`s type is backwards compatible, because instances of the old version will still be instances of the new version, right?