On Fri, 2009-11-27 at 00:33 +0000, Ross Paterson wrote:

As I understand it, the Haskell Platform timetable means this will take some time.

I think the ultimate aim should be that everyone moves to transformers and monads-fd (probably with some renaming of modules in the latter), and mtl disappears. If we decide on that, this is we could get there:

1. rename the modules in monads-fd to their final names. (We also need suggestions for what those names should be.) 2. release mtl-2.0 as a deprecated compatibility layer over transformers and monads-fd, and get all users to hide all versions of mtl, including the new one. 19 packages on hackage must be updated to work with the new version. 3. encourage authors to upgrade their packages to depend on transformers and (possibly) monads-fd in place of mtl. 4. after a couple of cycles, remove mtl from the platform.

Could someone remind me why it's better for use to ask everyone to switch to monads-fd / transformers rather than to mtl-2? Does that make the transition easier? If it makes little difference I'd suggest making mtl-2 the new recommendation (with whatever content you've all agreed) simply because it's easier to explain to everyone else. Duncan

On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson wrote:

On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:

...

Could someone remind me why it's better for use to ask everyone to switch to monads-fd / transformers rather than to mtl-2? Does that make the transition easier?

The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity.  Unless one of these packages is hidden, people using ghci or ghc --make will have problems.

I've happily used LANGUAGE PackageImports to handle transformer / mtl conflicts. I don't see why either one must change their module names and there are obvious disadvantages. Thomas

On Sat, 28 Nov 2009, Thomas DuBuisson wrote:

On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson wrote:

...

The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity.  Unless one of these packages is hidden, people using ghci or ghc --make will have problems.

I've happily used LANGUAGE PackageImports to handle transformer / mtl conflicts. I don't see why either one must change their module names and there are obvious disadvantages.

This PRAGMA is only available in GHC, is it?

On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:

On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:

...

On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:

...

Could someone remind me why it's better for use to ask everyone to switch to monads-fd / transformers rather than to mtl-2? Does that make the transition easier?

The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity. Unless one of these packages is hidden, people using ghci or ghc --make will have problems.

Right, so having transformers + mtl is bad, but why do we want to end up with a situation where we have both? If you've all agreed what should go into the new monad package, can't we call that mtl-2 ? Why would we want to define things in one package and re-export them in another?

Because there is not one new monad package, but two. The idea is to split the mtl package to decouple monad transformers from functional dependencies. The transformers part can then be used in Haskell 98 code, or with type classes using type functions. Exposed modules from mtl are split between the resulting two packages, so neither is a replacement for mtl-1. As I said above, having both would be a transitional arrangement, on the way to replacing mtl with the two packages split from it. mtl-2 is an attempt to smooth that transition, but it would eventually go away.

On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts

wrote:

On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:

...

On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:

...

On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:

...

On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:

...

Could someone remind me why it's better for use to ask everyone to switch to monads-fd / transformers rather than to mtl-2? Does that make the transition easier?

The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity. Unless one of these packages is hidden, people using ghci or ghc --make will have problems.

Right, so having transformers + mtl is bad, but why do we want to end up with a situation where we have both? If you've all agreed what should go into the new monad package, can't we call that mtl-2 ? Why would we want to define things in one package and re-export them in another?

Because there is not one new monad package, but two. The idea is to split the mtl package to decouple monad transformers from functional dependencies. The transformers part can then be used in Haskell 98 code, or with type classes using type functions. Exposed modules from mtl are split between the resulting two packages, so neither is a replacement for mtl-1. As I said above, having both would be a transitional arrangement, on the way to replacing mtl with the two packages split from it. mtl-2 is an attempt to smooth that transition, but it would eventually go away.

Ok, how about this:

transformers H98 bits, registered hidden by default mtl 2 re-exports transformers, adds type function stuff mtl-fd alternative that uses FDs, hidden by default

I'm not sure what you agreed, if you chose the FD one as default then use mtl-tf as the alternative. Whichever you have chosen as the recommended stuff should be called mtl 2, because that is the easiest to explain to everyone.

So all the packages now using mtl-1, move up to mtl 2. Then for packages that only want transformers, they depend on transformers. Similarly for the mtl-fd alternative (and whether that re-exports transformers or whether such packages should depend on transformers + mtl-fd is up to you).

Users of ghci / ghc --make will end up using mtl 2 by default and there will be no module name clashes because transformers and mtl-fd will by hidden by default (Cabal-1.6+ can do that). The hiding does not affect cabal packages of course.

Duncan

Are you saying that mtl-2 would be the equivalent of transformers + monads-tf? That might not be a good call; monads-fd is probably more popular than monads-tf.

Michael

On Sun, Nov 29, 2009 at 9:37 PM, Alexander Dunlap < alexander.dunlap@gmail.com> wrote:

On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman wrote:

...

On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts wrote:

...

On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:

...

On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:

...

On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:

...

On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > Could someone remind me why it's better for use to ask everyone

...

...

...

...

...

> switch to monads-fd / transformers rather than to mtl-2? Does

...

...

...

...

...

> make > the transition easier?

The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity. Unless one of these packages is hidden, people using ghci or ghc --make will have problems.

Right, so having transformers + mtl is bad, but why do we want to end up with a situation where we have both? If you've all agreed what should go into the new monad package, can't we call that mtl-2 ? Why would we want to define things in one package and re-export them in another?

Because there is not one new monad package, but two. The idea is to split the mtl package to decouple monad transformers from functional dependencies. The transformers part can then be used in Haskell 98 code, or with type classes using type functions. Exposed modules from mtl are split between the resulting two packages, so neither is a replacement for mtl-1. As I said above, having both would be a transitional arrangement, on the way to replacing mtl with the two packages split from it. mtl-2 is an attempt to smooth that transition, but it would eventually go away.

Ok, how about this:

transformers H98 bits, registered hidden by default mtl 2 re-exports transformers, adds type function stuff mtl-fd alternative that uses FDs, hidden by default

I'm not sure what you agreed, if you chose the FD one as default then use mtl-tf as the alternative. Whichever you have chosen as the recommended stuff should be called mtl 2, because that is the easiest to explain to everyone.

So all the packages now using mtl-1, move up to mtl 2. Then for packages that only want transformers, they depend on transformers. Similarly for the mtl-fd alternative (and whether that re-exports transformers or whether such packages should depend on transformers + mtl-fd is up to you).

Users of ghci / ghc --make will end up using mtl 2 by default and there will be no module name clashes because transformers and mtl-fd will by hidden by default (Cabal-1.6+ can do that). The hiding does not affect cabal packages of course.

Duncan

Are you saying that mtl-2 would be the equivalent of transformers + monads-tf? That might not be a good call; monads-fd is probably more

to that popular

...

than monads-tf.

Michael

What is the plan for letting the two co-exist? Is everyone going to have to write instances that work with both monads-{tf,fd} and then export duplicate functions that have monad classes in their signatures? It seems like if we can't have a nice way to use both, we ought to just pick one and deprecate the other.

Alex

Sounds reasonable to me. Shall we take a vote on which one it'll be? If FunDeps is really being deprecated, it would appear that tf is the way forward... Michael

On Sun, 2009-11-29 at 21:08 +0200, Michael Snoyman wrote:

...

Ok, how about this:

transformers H98 bits, registered hidden by default mtl 2 re-exports transformers, adds type function stuff mtl-fd alternative that uses FDs, hidden by default

Are you saying that mtl-2 would be the equivalent of transformers + monads-tf? That might not be a good call; monads-fd is probably more popular than monads-tf.

Yes mtl-2 would be transformers + monads-${the-right-one} Though more precisely, it'd re-export transformers and contain monads-${the-right-one}. I'm not really saying whether it should be the tf or fd version. I've not been taking part in that discussion. But other people have been discussing it and whichever one it is that they agree is the right default, that one should be labelled as mtl version 2. Also, I should say that it would be wrong to push the choice of FDs/TFs onto everyone. We should just pick one. Some people know the difference and can select an alternative. Everyone else just wants to use the same one as everyone else is using. Duncan

Edward Kmett wrote:

As a straw man proposal to get things started:

transformers: Control.Monad.Foo.Transformer - for the actual data type for FooT

mtl 2: Control.Monad.Foo.Class - exports just the fundep-based typeclass and no instances, like now. Control.Monad.Foo - exports the instances for the fundep based version and re-exports the Transformer and Class module contents.

mtl-tf: Control.Monad.Foo.Family.Class - exports just the type-family based typeclass Control.Monad.Foo.Family - exports the instances of the typefamily base version and re-exports the Transformer and Family.Class modules

This will safely let most libraries just use a constraint on mtl >= 1.2 && <= 2.1 in which case their code works across both versions, and if someone wants to use mtl-tf for clarity in their code, it will introduce no complications regardless of what libraries they import as long as those libraries can support both versions.

It's consistent and avoids name-clashery, which is nice. But I thought transformers had everything in one file? Maybe I'm thinking of a different monad transformer library... I think keeping fundeps as the default is probably best. It maintains instance definitions in old code across the version boundary, and it also maintains support with Hugs for folks who care about that. If, in the future, the community decides that fundeps are bad and TFs are good then we can make that switch in mtl-3. Even though a lot of folks are leaning that way now, I don't think there's a clear consensus yet to deprecate fundeps. Conflating the fundep-vs-TF debate in with the mtl-vs-transformers debate is just going to drag things out longer IMO. -- Live well, ~wren

On Mon, Nov 30, 2009 at 3:03 AM, wren ng thornton < wren@community.haskell.org> wrote:

Edward Kmett wrote:

...

As a straw man proposal to get things started:

transformers: Control.Monad.Foo.Transformer - for the actual data type for FooT

Feel free to amend that to keep the monad transformers where they are under Control.Monad.Trans.Foo - I hadn't checked before writing that out and have no real reason to move them. -Edward Kmett

On Mon, Nov 30, 2009 at 6:50 PM, Ross Paterson wrote:

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.

True. Like I said, I'd be happy with either way.

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.

I agree that perfect backwards compatibility is impossible. That said, unlike the type aliases, these are all cases where something new would work that didn't previously. Library code that wanted to be backwards compatible could avoid using the new instances, and the more permissive Functor instances shouldn't break any code that worked before unless that code was defining its own local version of Applicative, Alternative, etc. which were constrained by the restrictive Functor definitions to not work in the most permissive form anyway, so where needed, library code could work around using WrappedMonad, etc. in a way that would be compatible. It is true, that it would constrain the design of the mtl to carry a handful of handy (or burdensome, depending on your perspective) tutorial constructors around, but note that the functions themselves for working with the simpler type are still contained in transformers, so the function count doesn't really change either way. But the other way says that all of the libraries that re-export functionality on top of the mtl must discard coverage of the non-transformer case when linked against the old mtl. Both options suck, but only one provides no way out except to force someone up to the new version that they may not be able to use because of other package requirements. I have yet to see any major migration to a new version of a library that isn't more or less plug in compatible with the old version actually take hold (witness current adoption levels of parsec 3 & quickcheck 2). I hope this doesn't across as too cynical. I just figured that someone should play devil's advocate, before things got drowned in a sea of +1s. -Edward Kmett _______________________________________________

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sun, Nov 29, 2009 at 07:48:56PM +0000, Duncan Coutts wrote:

I'm not really saying whether it should be the tf or fd version. I've not been taking part in that discussion.

You haven't missed anything. I think we're a long way off being ready to make a final choice between FDs and TFs. For one thing neither of them is standard, and both monads-* packages also require other non-standard extensions. But we are at the point where we can decide to make FDs optional, though that hasn't been decided yet either. That's not to say that the HP shouldn't present a pre-packaged choice (probably FDs for some time), just that it shouldn't get in the way of alternatives.