Could iteratee depend on mtl instead of transformers?

[Duncan Coutts]

On Tue, 2009-11-17 at 09:11 +0000, Sittampalam, Ganesh wrote:

> > 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
> etc.
> 
> http://www.haskell.org/pipermail/libraries/2009-March/011471.html
> 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.

We can use hackage and the platform to help manage the transition too.
So I don't think it's necessary to go for a minimally breaking design.
My opinion is you should go for whatever you can all agree is the best
design, and then we manage the transition.

I suggest that the strategy should be to:

      * decide what the best "new" monad library should be (consensus
        between the various monad package authors and other experts)
      * play with it as much as possible first to work out the kinks
      * adjust hackage to make old packages not break by using a
        preference on mtl < 2
      * adjust hackage to require new packages use an upper bound on
        mtl, indicating if they're compatible with mtl-2 or not
      * release mtl-2
      * once the experts are happy with mtl-2, to include it into the
        next Haskell Platform release and encourage everyone to switch
        over.

For example, the next platform release will use QC2 and that should help
resolve the problem we have now where half the packages are still using
QC1 (since that was the version that shipped with ghc and the previous
HP release).

Duncan