* Ben Foppa
The IncoherentInstances in extensible-transformers bothers me as well - especially since I'm not very familiar with the unhappy cases of IncoherentInstances.
The problem with IncoherentInstances is that when there's no reason to pick a specific instance, the compiler is happy to pick a general one, even if the more specific one is intended. In your case it is not obvious that this can be a problem. Unlike many "applications" of IncoherentInstances, that look like instance Cls a where ... yours have a superclass constraint involving the same class, so it's not trivial to discharge. I *think* that as soon as a monad stack doesn't contain two identical transformers, the bad case shouldn't happen. But I am not too confident here.
One big problem with extensible-transformers is that it doesn't expose the inner Monad itself (mainly because there isn't one), which creates an issue for code that needs its transformers to transform more than just "something"
Not sure what you mean. Can you give an example?
The big plus (and minus) for extensible-transformers is that it can lift into the existing transformers stacks - it doesn't require rewriting the effects like extensible-effects or monad-classes. It's bound by the same pros and cons as transformers, but it's easy to integrate into existing code.
monad-classes builds on transformers, too. It sits on the same layer as mtl, providing classes around transformers' types. That was the main motivation behind monad-classes — it turned out that the free monad approach is much slower than plain transformers. Roman