On 11/2/10 12:01 PM, Edward Kmett wrote:

I am unaware of any concerns not mentioned in that proposal.

+1 to finally getting this change over and done with and mending the rift in the community forced by the current situation once and for all.

Nor am I, and +1. -- Live well, ~wren

On Wed, Nov 3, 2010 at 5:50 AM, Isaac Dupree wrote:

mtl-2.0 was just recently uploaded.  If it's easy, I would cautiously wish to wait a month before committing-for-sure to mtl-2 in the platform, and see if there are unexpected transition difficulties.  Any issues that users notice will surely get mentioned on the mailing-lists.  Though, the proposal page (and past experience with transformers/monads-fd) does seem to have investigated the difficulties pretty well; and if the difficulties are not much more than estimated, then they seem worth the costs to me.

We have about a month and a half to figure it out. During that time we'll try to migrate all HP packages to mtl-2 (and perhaps some other important packages.) If that doesn't cause problems, we can go ahead with mtl-2 in the next. Release, if it does cause problems, well then mtl-2 will not make it. Put another way, all accepted proposals are conditionally excepted on actually being possible to implement. :)

(Is there time pressure? Given http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable I am not sure.  Incidentally it suggests that we technically missed the proposal deadline by one day depending on timezones - Nov 1 vs Nov 2 - which I'm not inclined to worry about.  The page history says Don Stewart wrote that timeline mid-July.)

That's my (and the rest of the steering committee's) fault for not calling for consensus sooner when the discussion died out. My apologies. Johan

Currently the following 32 library packages directly depending on mtl are broken by the changes (including reasons and number of packages that directly or indirectly depend on these): applicative-extras-0.1.6 Applicative instance (9 clients) blogination-0.5 Applicative instance (no clients) category-extras-0.53.5 Functor constraint (15 clients) csound-expression-0.0 base monad members (no clients) derive-2.3.0.2 Applicative instance (13 clients) encoding-0.6.3 base monad members (15 clients) FileManip-0.3.3.1 base monad members (13 clients) FileManipCompat-0.15 base monad members (7 clients) HaLeX-1.1.1 base monad members (no clients) happstack-server-0.5.0.2 Functor constraint (32 clients) hashed-storage-0.5.3 Functor constraint (6 clients) HaskellNet-0.2.3 base monad members (no clients) hmk-0.9.7 Applicative instance (1 clients) hssqlppp-0.2.0 Error instance (1 clients) jmacro-0.3.2 base monad instance (no clients) kibro-0.4.3 Functor constraint (11 clients) llvm-ht-0.7.0.0 base monad members (2 clients) monad-param-0.0.2 Functor constraint (no clients) MonadRandom-0.1.5 Functor constraint (13 clients) nntp-0.0.3 Functor constraint (no clients) OpenCLRaw-1.0.1001 base monad members (no clients) open-witness-0.1.1 base monad members (no clients) plot-0.1.2.3 base monad members (1 clients) random-fu-0.1.0.0 base monad instance (3 clients) redHandlers-0.1 Functor constraint (1 clients) she-0.1 Applicative instance (no clients) swish-0.2.1 base monad members (no clients) tls-0.2 Functor constraint (6 clients) Twofish-0.2 base monad instance (no clients) xmonad-contrib-bluetilebranch-0.9.1.4 base monad members (1 clients) yhccore-0.9.1 base monad instance (3 clients) A further concern is that we now have 138 packages whose dependencies exclude mtl-2 and 8 (and rising) whose dependencies require it. That will prevent an increasing number of packages from building.

On Thu, Nov 04, 2010 at 05:39:29PM +0100, Johan Tibell wrote:

So all these libraries are missing an upper bound on their mtl dependencies?

I think it would be better if they were upgraded to mtl-2, or made to work with both versions. (If the problem is a Functor constraint, this can be done by just adding such a constraint in addition to the Monad constraint, as was just done to the cgi package.)

...

A further concern is that we now have 138 packages whose dependencies exclude mtl-2 and 8 (and rising) whose dependencies require it. That will prevent an increasing number of packages from building.

Is that really the case? Libraries can build against older versions of another library? This gives library authors time to upgrade their dependencies and fix compilation errors. Problems should only show up when libraries don't follow the PVP.

% cabal install --dry-run atomo-0.2 Resolving dependencies... cabal: cannot configure monads-fd-0.1.0.3. It requires mtl ==2.* For the dependency on mtl ==2.* there are these packages: mtl-2.0.0.0. However none of them are available. mtl-2.0.0.0 was excluded because haskeline-0.6.3.1 requires mtl ==1.1.* This will become more common as more packages are upgraded to mtl-2.

On Thu, Nov 4, 2010 at 10:05 AM, Ross Paterson wrote:

On Thu, Nov 04, 2010 at 05:39:29PM +0100, Johan Tibell wrote:

% cabal install --dry-run atomo-0.2 Resolving dependencies... cabal: cannot configure monads-fd-0.1.0.3. It requires mtl ==2.* For the dependency on mtl ==2.* there are these packages: mtl-2.0.0.0. However none of them are available. mtl-2.0.0.0 was excluded because haskeline-0.6.3.1 requires mtl ==1.1.*

This will become more common as more packages are upgraded to mtl-2.

For what it's worth, that's been fixed by the just-uploaded haskeline-0.6.3.2. (I was pleased to discover that I only needed to bump the constraint in its build-depends.) -Judah

On Thu, Nov 04, 2010 at 08:36:24PM -0500, Jeremy Shaw wrote:

I intend to upload a new version of happstack 0.5 which has the proper constraints. And happstack 6 will be migrated to transformers/monads-fd.

mtl-2.0.0.0 is now a copy of what monads-fd was, and monads-fd is now a deprecated stub re-exporting mtl-2.0.0.0. So you'll want to migrate to transformers/mtl-2. But in your case, on line 578 of src/Happstack/Server/SimpleHTTP.hs: getFilter m = WebT $ ErrorT $ fmap lft $ getFilter (runErrorT $ unWebT m) If you replace fmap with liftM, it will build with both old and new versions of the mtl package.

On Wed, Nov 03, 2010 at 12:44:33PM -0400, Brent Yorgey wrote:

As an experience report, I just ported the diagrams package to mtl-2. As a matter of fact it did require some changes, because one place in the code explicitly used the Cont constructor which had to be changed to ContT (and some Identity wrapping and unwrapping added). But it wasn't a big deal and it works fine now.

The transformers package has (in Control.Monad.Trans.Cont) a function cont :: ((a -> r) -> r) -> Cont r a to serve as a plugin replacement for the Cont constructor (and similarly for the other base monads that are now type synonyms). One could argue that these should be re-exported by mtl-2, but I was aiming for maximum compatibility.

Hi, Additionally, it would be very useful to have the MaybeT monad transformer included into mtl-2. While migrating my packages from transformers/monads-fd to the new mtl, the absence of MaybeT was the only problem I came across. Cheers, Sebastiaan On Nov 6, 2010, at 3:26 PM, Ross Paterson wrote:

On Tue, Nov 02, 2010 at 02:17:03PM +0100, Johan Tibell wrote:

...

This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers

Are there any unresolved concerns?

Brent Yorgey's report raises one: the following functions, defined in the transformers package as replacements for data constructors for the base monads, should probably be re-exported by the new mtl:

Control.Monad.Cont: cont :: ((a -> r) -> r) -> Cont r a Control.Monad.RWS.Lazy: rws :: (r -> s -> (a, s, w)) -> RWS r w s a Control.Monad.RWS.Strict: rws :: (r -> s -> (a, s, w)) -> RWS r w s a Control.Monad.Reader: reader :: (r -> a) -> Reader r a Control.Monad.State.Lazy: state :: (s -> (a, s)) -> State s a Control.Monad.State.Strict: state :: (s -> (a, s)) -> State s a Control.Monad.Writer.Lazy: writer :: (a, w) -> Writer w a Control.Monad.Writer.Strict: writer :: (a, w) -> Writer w a

Is it really a problem that it goes beyond the primary mission? If so, I'll make a separate proposal. And maybe I'll even setup the patch. On Nov 6, 2010, at 4:37 PM, Ross Paterson wrote:

On Sat, Nov 06, 2010 at 04:17:05PM +0100, Sebastiaan Visser wrote:

...

Additionally, it would be very useful to have the MaybeT monad transformer included into mtl-2.

While migrating my packages from transformers/monads-fd to the new mtl, the absence of MaybeT was the only problem I came across.

That would be going beyond the primary mission of replacing the existing mtl, though (and transformers still exports MaybeT).

Adding MaybeT would be a change that doesn't need any proposal -- the maintainers right overrides. Whoever maintains mtl-2 could choose to do this without discussion. haskell:

Is it really a problem that it goes beyond the primary mission?

If so, I'll make a separate proposal. And maybe I'll even setup the patch.

On Nov 6, 2010, at 4:37 PM, Ross Paterson wrote:

...

On Sat, Nov 06, 2010 at 04:17:05PM +0100, Sebastiaan Visser wrote:

...

Additionally, it would be very useful to have the MaybeT monad transformer included into mtl-2.

While migrating my packages from transformers/monads-fd to the new mtl, the absence of MaybeT was the only problem I came across.

That would be going beyond the primary mission of replacing the existing mtl, though (and transformers still exports MaybeT).

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

On Sat, Nov 06, 2010 at 05:02:39PM +0100, Sebastiaan Visser wrote:

Is it really a problem that it goes beyond the primary mission?

It might be if it slows down the HP process. However I agree that instances of the mtl classes for MaybeT (and IdentityT) should be added, since there's nowhere else to put them without making them orphans. I'm not so sure about copying the transformers modules, though.

On 10-11-06 11:17 AM, Sebastiaan Visser wrote:

Hi,

Additionally, it would be very useful to have the MaybeT monad transformer included into mtl-2.

While migrating my packages from transformers/monads-fd to the new mtl, the absence of MaybeT was the only problem I came across.

What was your reason for doing this, if I may ask? Are there plans to deprecate transformers or monads-fd any time soon? I'm asking because my packages depend on transformers as well, and I don't see any reason to replace this dependency by mtl-2. If that is the recommended approach from now on, I can certainly do it.

Cheers, Sebastiaan

On Nov 6, 2010, at 3:26 PM, Ross Paterson wrote:

...

On Tue, Nov 02, 2010 at 02:17:03PM +0100, Johan Tibell wrote:

...

This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers

Are there any unresolved concerns?

...

Brent Yorgey's report raises one: the following functions, defined in the transformers package as replacements for data constructors for the base monads, should probably be re-exported by the new mtl:

Control.Monad.Cont: cont :: ((a -> r) -> r) -> Cont r a Control.Monad.RWS.Lazy: rws :: (r -> s -> (a, s, w)) -> RWS r w s a Control.Monad.RWS.Strict: rws :: (r -> s -> (a, s, w)) -> RWS r w s a Control.Monad.Reader: reader :: (r -> a) -> Reader r a Control.Monad.State.Lazy: state :: (s -> (a, s)) -> State s a Control.Monad.State.Strict: state :: (s -> (a, s)) -> State s a Control.Monad.Writer.Lazy: writer :: (a, w) -> Writer w a Control.Monad.Writer.Strict: writer :: (a, w) -> Writer w a

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

On 11/06/10 10:26, Ross Paterson wrote:

On Tue, Nov 02, 2010 at 02:17:03PM +0100, Johan Tibell wrote:

...

This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers

Are there any unresolved concerns?

Brent Yorgey's report raises one: the following functions, defined in the transformers package as replacements for data constructors for the base monads, should probably be re-exported by the new mtl:

People probably have local variables named "cont" and "state" in their code already. Especially in code that uses the Cont and State monads already, I imagine. Well, I suppose we can live with that. -Isaac

On Wed, Nov 10, 2010 at 12:24:44AM -0500, Isaac Dupree wrote:

On 11/06/10 10:26, Ross Paterson wrote:

...

Brent Yorgey's report raises one: the following functions, defined in the transformers package as replacements for data constructors for the base monads, should probably be re-exported by the new mtl:

People probably have local variables named "cont" and "state" in their code already. Especially in code that uses the Cont and State monads already, I imagine. Well, I suppose we can live with that.

Yes they do, and this will trigger warnings with -Wall. But none of the packages in hackage that import Control.Monad.Cont define a top-level function cont (or similarly for the others), so it shouldn't break anything.

johan.tibell:

All,

On Tue, Nov 2, 2010 at 2:17 PM, Johan Tibell wrote:

...

This is a call for consensus for the following proposal:

   http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers

Are there any unresolved concerns?

Deadline: 2 weeks (Nov 14)

Since no blocking objections were raised, I declare this proposal accepted.

- There were several experience reports of upgrading to mtl-2. Thanks for sharing. - Isaac Dupree pointed out that we need to make sure there are no unexpected transition difficulties, but didn't think it's was a blocking concern. I think we agreed that all proposals are conditionally accepted on actually being possible to implement.

Thanks to everyone for trying to sticking with the process. We (as in the steering committee) will do our best to make it a bit smoother next time around.

Johan Tibell (with his Haskell Platform Steering Committee hat on)

Thanks Ross, for proposing, and everyone else for contributing! Well done! I have now added mtl+transformers to the HP 2011.1 release candidate .cabal file. -- Don

On Tue, Nov 16, 2010 at 11:47:40AM +0200, Yitzchak Gale wrote:

Johan Tibell wrote:

...

This is a call for consensus for the following proposal:    http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers Are there any unresolved concerns?

Please create a document (perhaps on the wiki?) with clear instructions how to resolve any incompatibilities for the upgrade.

The "Upgrading to mtl-2" section in the above-linked page is a start in this direction.