Could iteratee depend on mtl instead of transformers?

[Edward Kmett]

For symmetry I agree both should probably be renamed.

What are the current breaking changes?

I gather from the discussion that State is no longer separate from StateT,
along with Reader, Writer, RWS, Error, mutatis mutandis to obviate the need
for both a base monad and transformer.

I guess the question is then, when should code start looking to changing
their dependencies over to monads-tf and monads-fd?

A cleanly demarked cut over would be useful to get us out of this limbo
state that helps nobody.

-Edward Kmett

On Tue, Nov 17, 2009 at 11:04 AM, Ross Paterson <ross at soi.city.ac.uk> wrote:

> On Tue, Nov 17, 2009 at 09:09:07AM -0500, Edward Kmett wrote:
> > I like that transformers is Haskell 98 and presents a common core. I
> > think that factoring it out is a laudable goal.
> >
> > However, my very problem is that monads-fd and monads-tf are mutually
> > incompatible. It fragments the community of monad combinator users
> > even further.
> >
> > If monads-fd sat in the existing location of mtl or was exported there
> > by an mtl compatibility layer and monads-tf used a different namespace
> > then you would have a clean solution in which both could be used in
> > the same code, because both could be loaded.
>
> The proposal is to make the next version of mtl a near-compatibility layer
> over monads-fd and transformers; it doesn't involve monads-tf directly.
> We could just rename all the modules in monads-tf (which aimed to mirror
> mtl-tf), or perhaps rename the modules in both monads-fd and monads-tf.
> Perhaps we should trim both packages to just the class modules (the others
> are re-exports mirroring mtl) and relocate those in the module hierarchy:
>
>    Control.Monad.Cont.Class
>    Control.Monad.Error.Class
>    Control.Monad.RWS.Class
>    Control.Monad.Reader.Class
>    Control.Monad.State.Class
>    Control.Monad.Writer.Class
>
> They both have the same Cont class; it need not be duplicated.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20091117/177cb4e0/attachment.html