MTL vs Transformers. Any status update?

Ross Paterson ross at soi.city.ac.uk
Mon Nov 30 18:50:27 EST 2009


On Sun, Nov 29, 2009 at 07:29:47PM -0500, Edward Kmett wrote:
> The final issue is whether or not it is a good idea to eliminate the
> simpler non-transformer versions of the monads.
>
> Without them, libraries that provide instances for the various monads
> cannot provide instances for State and StateT in a way that lets them
> work compatibly with both versions.
>
> So, an issue that I would like to talk about separately is if we
> _should_ be dropping the basic State, Reader, Writer, etc. constructors.
> They have definite pedagogical value, and have easier to understand
> behavior for introductory purposes.  If we kept those then ALL code
> that worked with mtl 1.2 would be compatible with mtl 2, which strikes
> me as a desirable property.  This has the benefit that it is easier
> to write libraries that export instances.  I think we would be remiss
> in not at least considering the issue.  On the other hand, I don't
> know how many libraries provide instances for the monads in the MTL.
> I have a few in my monoids library, but I'd be willing to go either way.

The benefit of defining these as type synonyms is that the Haskell 98
transformers package has the same functions operating on both the base
monad and the corresponding transformer; there is no need to define two
versions of everything.  Similarly fewer instances are required in the
monad class packages.

I think the pedagogical issue can be handled in other ways, and that
making compatibility with the current mtl an overriding requirement
would be unduly constraining.  In any case there would be no complete
compatibility, as transformers adds Applicative and Alternative instances,
and also changes the constraints on Functor instances.


More information about the Libraries mailing list