Could iteratee depend on mtl instead of transformers?

Sittampalam, Ganesh ganesh.sittampalam at
Tue Nov 17 04:11:27 EST 2009

Johan Tibell wrote:

> I went back and reread the two linked threads and I'm no wiser as to
> why we should prefer transformers.

The key point of transformers is that mtl is approximately the same as
the combination of transformers + monads-fd - where transformers is H98,
and monads-fd has the functional dependency based type classes
(MonadState etc).

So making the split means that only code that actually needs those
classes need depend on them. Since the future of fundeps is up in the
air, this seems like a better position to be in. It also enables people
to use monads-tf (i.e. type family based classes) without using an
incompatible set of transformer types (which is what mtl-tf contains).

> I'd like to see an argument
> describing the benefits of using transformers vs the drawbacks
> (including how much code would break).   

Migration would be by releasing mtl-2.0 which re-exports transformers +
monads-fd. There are a few changes in transformers compared to mtl which
clean up the design but at the cost of breaking backwards compatibility
- one prominent example is that Functor instances in the transformer
types now depend on Functor instances in the base types, where as mtl
has them depending on Monad instances. Another change (which isn't
crucial to the migration) is to replace the currently separate State,
Reader etc types with type synonyms to StateT Identity, ReaderT Identity
roughly summarises how much of hackage would break as of then (March
09). I haven't had time to rerun the experiment recently, which is one
reason I haven't made a formal proposal yet. I also think that I didn't
do anything to test packages that follow the PVP and thus wouldn't have
picked up the newer mtl due to having an upper bound on their mtl
dependency. Of course such well-behaved packages won't break immediately
but will need code changes at some point to be brought up to date.

None of the compilation problems are hard to fix, as far as I know.


 Please access the attached hyperlink for an important electronic communications disclaimer: 

More information about the Libraries mailing list