[Haskell-cafe] extensible-transformers

[Roman Cheplyaka]

* Ben Foppa <benjamin.foppa at gmail.com> [2014-07-10 12:45:58-0400]
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140710/249c771b/attachment.sig>