[Haskell-cafe] Improving MTL instances (was: Overlapping/Incoherent instances)

Luke Palmer lrpalmer at gmail.com
Mon Oct 13 22:02:46 EDT 2008

On Mon, Oct 13, 2008 at 1:29 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:
> Of course, the point of this message isn't just to complain.  The
> overlap implementation was abhorrent and it *is* better now than it
> was before.  But perhaps there is an abstraction we are missing that
> would allow for better interoperability.  For example, the
> type-compose library documentation at
> http://haskell.org/haskellwiki/TypeCompose mentions that (f :. g) is
> an applicative functor if both f and g are applicative functors, which
> means there is a generic "transformer" for all applicative functors!
> The presense of >>=/join for monads make this more difficult, although
> there is the "product" definition:
>> newtype Product m n a = Prod { runProd :: m (Either a (Product n m a)) }
> which handles nesting joins by just nesting the monads recursively.
> But in this case it is up to the user to figure out how to untangle
> the spaghetti created, so that's no good.
> So, does anyone have any good ideas for improving the interoperability of MTL?


This was on planet haskell a little over a month ago.  It describes
how any monad whose operations look like f (m a) -> m a for some
functor f can be automatically lifted.   If it's possible to phrase a
basis for operations on some transformer this way and then provide
"adapters" for ease of use, that would be one excellent way to improve
interoperability.  Some caveats are mentioned in the post...


More information about the Haskell-Cafe mailing list