roma at ro-che.info
Thu Jul 10 20:18:04 UTC 2014
* 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
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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Haskell-Cafe