Haskell Platform Proposal: add transformers and revise the mtl package to depend on it

The proposal is that version 2 of the mtl package be the current contents of the monads-fd package, which depends on the transformers package: http://hackage.haskell.org/package/monads-fd http://hackage.haskell.org/package/transformers An up to date copy of this text is kept at: http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages. http://trac.haskell.org/haskell-platform/wiki/AddingPackages Review comments should be sent to the libraries mailing list by October 15 so that we have time to discuss and resolve issues before the final deadline on November 1. http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable == Proposer == * Ross Paterson (maintainer of transformers and monads-fd) If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package). == Rationale == Monad transformers are widely used, but the MTL interface is tied to functional dependencies, whose future is in doubt. Many people want to try out interfaces based on type functions, or without using experimental type class features, but their interfaces will then be incompatible with libraries using mtl. The idea is to factor out the monad transformers as the Haskell 98 package. The objectives for this package are: 1. that it be as useful as possible by itself, so that it can replace many uses of mtl. 2. that it serve as a base for other packages adding type classes based on either functional dependencies (e.g. mtl) or type functions, with interfaces referring to the monad transformers being compatible across the different libraries. The transformers and monads-fd packages have been in use for over 18 months, and are used by 112 and 23 packages respectively. The split structure has been shown to be viable, but its existence in parallel with mtl has meant extra effort for authors of client packages. It is time to complete the transition. == Structure == The current mtl is to be split in two: * transformers is a Haskell 98 package containing * base functors (Data.Functor.Constant and Data.Functor.Identity), * operations on functors (Data.Functor.Compose and Data.Functor.Product), * transformer classes (Control.Monad.Trans.Class and Control.Monad.IO.Class) and * concrete monad transformers with code to lift operators (Control.Monad.Trans.*). The package can be used on its own (see the Control.Monad.Trans.Class documentation for examples), or with packages adding type classes. * mtl-2 (the current monads-fd) depends on transformers and adds type classes using functional dependencies. It has the same modules as mtl-1 and usage is very close, except for the differences listed below. == Incompatibilities == The proposed interface of mtl-2 is close to that of mtl-1, but with the following differences (illustrated with Reader): * instances of Applicative and Alternative have been added as appropriate, e.g. instance (Applicative m) => Applicative (ReaderT r m) where ... instance (Alternative m) => Alternative (ReaderT r m) where ... Rationale: These classes postdate the MTL, and such instances have been repeatedly defined in various packages. They belong together with the type constructors. * Functor instances for monad transformers no longer require Monad where Functor is sufficient. Unfortunately this is incompatible because Functor is not a superclass of Monad, e.g. instance (Monad m) => Functor (ReaderT r m) where ... is replaced by instance (Functor m) => Functor (ReaderT r m) where ... Rationale: These instances are more general, and are consistent with the instances of other classes. * simple monads are now aliases for monad trasformers applied to Identity, e.g. newtype Reader r a = Reader { runReader :: r -> a } is replaced by type Reader r = ReaderT r Identity reader :: (r -> a) -> Reader r a reader f = ReaderT (Identity . f) runReader :: Reader r a -> r -> a runReader m = runIdentity . runReaderT m Rationale: This avoids repetition in the interfaces of both transformers and the proposed mtl-2. It makes transformers more useful on its own, and also saves clients of mtl from defining instances for both Reader r and ReaderT r and ensuring that they are consistent. * The instance Error String is restructured to avoid a type synonym instance: instance Error String where noMsg = "" strMsg = id is replaced by instance ErrorList a => Error [a] where strMsg = listMsg class ErrorList a where listMsg :: String -> [a] instance ErrorList Char where listMsg = id Rationale: This makes the instance Haskell 98, so it can be included in the transformers package. == Transition issues == In early September 2010, of the 510 buildable packages in hackage that directly depended on mtl, * 312 built unchanged with the proposed mtl-2 * 102 had a bounded mtl dependency (or a dependent package had) that excluded mtl-2 * 2 failed because of the recent move of the Monad (Either e) instance from mtl to base * 41 failed with the new mtl: * 11 because they defined their own Applicative instances (which can now be deleted) * 11 because of the changed constraint on Functor instances * 15 that used the constructors of base monads (which can be trivially replaced) * 3 that defined instances for base monads * 1 that defined an overlapping Error instance * 53 failed because they depended on one of the other failures The attached test report lists the packages involved. == Other issues == Some other issues have been raised with mtl over the years, but they are orthogonal to this proposal: * The MonadCont instance for StateT is not compatible with the monad transformer. The transformers package provides the correct lifting (in which callcc causes the state to rollback on entering the saved continuation), but also provides the MTL lifting for compatibility, and this is used by monads-fd. It could be switched to the correct lifting later. * The ErrorT monad transformer has an Error constraint, so that errors can be passed to the fail method of the Monad class. * ListT only works on commutative monads. Attachments * mtl-2.0.0.0.tar.gz (13.4 kB) -"proposed mtl-2.0.0.0.tar.gz", added by ross on 09/14/10 19:01:21. * test-Sep-2010 (21.3 kB) -"test of mtl-using packages in Sep 2010", added by ross on 09/15/10 20:05:56.

Hi,
Thanks for creating this proposal and doing a thorough analysis of the
issues, including the package breakage analysis.
On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
* simple monads are now aliases for monad trasformers applied to Identity, e.g.
newtype Reader r a = Reader { runReader :: r -> a }
is replaced by
type Reader r = ReaderT r Identity
reader :: (r -> a) -> Reader r a reader f = ReaderT (Identity . f)
runReader :: Reader r a -> r -> a runReader m = runIdentity . runReaderT m
Rationale: This avoids repetition in the interfaces of both transformers and the proposed mtl-2. It makes transformers more useful on its own, and also saves clients of mtl from defining instances for both Reader r and ReaderT r and ensuring that they are consistent.
I would like to know if this additional abstraction has a noticeable performance cost. Does anyone know of a benchmark that could be used to test this? Perhaps one involving State. Paying careful attention to inlining should help remove any overhead. == Transition issues ==
* 41 failed with the new mtl: * 11 because they defined their own Applicative instances (which can now be deleted) * 11 because of the changed constraint on Functor instances * 15 that used the constructors of base monads (which can be trivially replaced) * 3 that defined instances for base monads * 1 that defined an overlapping Error instance
Should we try to get these 41 package to add an upper bound on their mtl dependency before mtl-2 is released so they don't break? The authors could then migrate their code over to mtl-2 as soon as it has been published. If this proposal is approved, we should create a small wiki with migration tips. Cheers, Johan

On Thu, Sep 16, 2010 at 11:10:37AM +0200, Johan Tibell wrote:
On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
wrote: * 41 failed with the new mtl: * 11 because they defined their own Applicative instances (which can now be deleted) * 11 because of the changed constraint on Functor instances * 15 that used the constructors of base monads (which can be trivially replaced) * 3 that defined instances for base monads * 1 that defined an overlapping Error instance Should we try to get these 41 package to add an upper bound on their mtl dependency before mtl-2 is released so they don't break? The authors could then migrate their code over to mtl-2 as soon as it has been published.
If this proposal is adopted, sure, though upper bounds do cause other packages to break due to incompatible constraints. In the case of those with the Functor instance problem we can often do something that works both with the current version and the proposed version: either add a Functor instance for the argument monad or a Functor constraint to a type signature.

On Thu, Sep 16, 2010 at 11:10:37AM +0200, Johan Tibell wrote:
I would like to know if this additional abstraction has a noticeable performance cost. Does anyone know of a benchmark that could be used to test this? Perhaps one involving State.
With mtl-1, the following incr1 :: State Int () incr1 = do n <- get put $! n+1 incr2 :: StateT Int Identity () incr2 = do n <- get put $! n+1 generate the same Core code (except for casts).

Ross, Could you please add an "Open Issues" section where you keep track on any open issues/objections raised so far (a short summary is enough), to make sure that we deal with them all and to avoid them being rehashed. For example: Open Issues ========= 1. Performance monads when defined in terms of monad transformers. To ensure that defining the base monads in terms of their monad transformer version over the Identity monad the following benchmarks were run: <some benchmarks> These benchmarks show no performance difference. 2. More complicated type signatures due to using a monad transformer to define base monads. <etc> By documenting these decisions we can preempt needless rehashing of arguments and capture the consensus on these issues. Thanks! -- Johan

On Fri, Sep 17, 2010 at 01:18:47PM +0200, Johan Tibell wrote:
Could you please add an "Open Issues" section where you keep track on any open issues/objections raised so far (a short summary is enough), to make sure that we deal with them all and to avoid them being rehashed
I've added an "Issues raised" section.
2. More complicated type signatures due to using a monad transformer to define base monads.
I'm not sure what you mean here: do you mean inferred types?

On Fri, Sep 17, 2010 at 1:48 PM, Ross Paterson
Could you please add an "Open Issues" section where you keep track on any open issues/objections raised so far (a short summary is enough), to make sure
On Fri, Sep 17, 2010 at 01:18:47PM +0200, Johan Tibell wrote: that
we deal with them all and to avoid them being rehashed
I've added an "Issues raised" section.
Thanks!
2. More complicated type signatures due to using a monad transformer to define base monads.
I'm not sure what you mean here: do you mean inferred types?
Right, what GHC spits back at you if you have a type error. I'm not sure if it's an important issue. I believe GHC tries to use the type synonyms in the error messages. -- Johan

On Thu, Sep 16, 2010 at 5:23 AM, Ross Paterson
If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package).
So, if this proposal is accepted, then we would have: - transformers on HP. - mtl on HP (depending on transformers). - monads-tf on Hackage (depending on transformers). Wouldn't it be better to obsolete mtl and have: - transformers on HP. - monads-fd on HP (depending on transformers). - monads-tf on Hackage (depending on transformers). The naming would be more consistent. Thanks for biting the bullet! Cheers, -- Felipe.

On 16 September 2010 21:43, Felipe Lessa
On Thu, Sep 16, 2010 at 5:23 AM, Ross Paterson
wrote: If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package).
So, if this proposal is accepted, then we would have:
- transformers on HP. - mtl on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
Wouldn't it be better to obsolete mtl and have:
- transformers on HP. - monads-fd on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
The naming would be more consistent.
I'm leaning towards this solution for just this reason. Apart from the fact that the current mtl uses FDs, is there any reason why monads-fd is preferred over monads-tf? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Ivan Lazar Miljenovic schrieb:
On 16 September 2010 21:43, Felipe Lessa
wrote: On Thu, Sep 16, 2010 at 5:23 AM, Ross Paterson
wrote: If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package). So, if this proposal is accepted, then we would have:
- transformers on HP. - mtl on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
Wouldn't it be better to obsolete mtl and have:
- transformers on HP. - monads-fd on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
The naming would be more consistent.
I'm leaning towards this solution for just this reason. Apart from the fact that the current mtl uses FDs, is there any reason why monads-fd is preferred over monads-tf?
Then maybe mtl-2 could contain both monads-fd and monads-tf. But I see that monads-fd and monads-tf still use the same module names. Are there plans to disambiguate them?

On 16 September 2010 12:43, Felipe Lessa
On Thu, Sep 16, 2010 at 5:23 AM, Ross Paterson
wrote: If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package).
So, if this proposal is accepted, then we would have:
- transformers on HP. - mtl on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
Wouldn't it be better to obsolete mtl and have:
- transformers on HP. - monads-fd on HP (depending on transformers). - monads-tf on Hackage (depending on transformers).
The naming would be more consistent.
It's true that the naming scheme would be more consistent, however I think the more important point is to communicate clearly to users of the platform what it is that they need to do. Consider some Haskell programmer who is not reading this mailing list. They use the platform and mtl-1 in their code. If the next HP release contains mtl-2 then it is clear to them what they need to do: they just need to test their code against mtl-2 (fixing any compilation problems and adjusting build-depends version constraints). If on the other hand we removed mtl-1 from the platform then our example coder does not know what to do. It's much more work for them to discover that this new package monads-fd was just added to the platform and it seems to provide the same modules. Duncan

On Thu, Sep 16, 2010 at 11:21 AM, Duncan Coutts
It's true that the naming scheme would be more consistent, however I think the more important point is to communicate clearly to users of the platform what it is that they need to do.
Consider some Haskell programmer who is not reading this mailing list. They use the platform and mtl-1 in their code. If the next HP release contains mtl-2 then it is clear to them what they need to do: they just need to test their code against mtl-2 (fixing any compilation problems and adjusting build-depends version constraints). If on the other hand we removed mtl-1 from the platform then our example coder does not know what to do. It's much more work for them to discover that this new package monads-fd was just added to the platform and it seems to provide the same modules.
This is probably the last chance we have to deprecate the name 'mtl'. Is it doable to: - Add both mtl-2 and monads-fd to HP. - Instead of renaming monads-fd to mtl, re-export all monads-fd modules in mtl-2. - Mark all mtl-2 modules as deprecated and point to monads-fd. - After some time, remove mtl-2 from HP. Packages will still work as with OP's proposal, albeit printing many deprecation warnings. Cheers! =) -- Felipe.

On 16 September 2010 15:30, Felipe Lessa
On Thu, Sep 16, 2010 at 11:21 AM, Duncan Coutts
wrote: It's true that the naming scheme would be more consistent, however I think the more important point is to communicate clearly to users of the platform what it is that they need to do.
This is probably the last chance we have to deprecate the name 'mtl'.
Is this actually a problem? Duncan

+1 for the proposal in general
On 16 September 2010 23:47, Felipe Lessa
On Thu, Sep 16, 2010 at 11:42 AM, Duncan Coutts
wrote: This is probably the last chance we have to deprecate the name 'mtl'.
Is this actually a problem?
Not really. It's just for consistency.
I like Felipe's idea of deprecating the name mtl (in the form of the not-yet-existing library mtl-2) in favour of the existing (name+library) monads-fd. Many actively maintained packages already have a transformers+monads-fd dependency anyway. I'd expect the changes of this proposal will take about a year or so to shake out (eg. by the time the change is reflected in Debian stable / on random hackers' machines), and introducing the mtl-2 name would encourage maintainers to have (mtl-2 || monads-fd) dependencies in cabal files during that time. I think it'd be neater to just stick to the existing monads-fd name+library. (Also I think monads-fd is a more descriptive name than mtl, but perhaps I just don't like TLAs :) Conrad.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/16/10 10:42 , Duncan Coutts wrote:
On 16 September 2010 15:30, Felipe Lessa
wrote: This is probably the last chance we have to deprecate the name 'mtl'. Is this actually a problem?
It occurs to me that it's called "mtl" but will be exporting "monads-fd", leaving confusion as to whether "mtl" competes with, supersedes, is superseded by, or is unrelated to "transformers". If "mtl" exports "monads-fd", then the latter is the case... but is that true? Which is the point. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyS73QACgkQIn7hlCsL25UNNQCfY+NN+diasTVMQn60s4AMWO2r 6CEAoKVAOi8NQR1TAApU4Y3ssu8JpAYT =x4kz -----END PGP SIGNATURE-----

On 17 September 2010 13:32, Brandon S Allbery KF8NH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 9/16/10 10:42 , Duncan Coutts wrote:
On 16 September 2010 15:30, Felipe Lessa
wrote: This is probably the last chance we have to deprecate the name 'mtl'. Is this actually a problem?
It occurs to me that it's called "mtl" but will be exporting "monads-fd", leaving confusion as to whether "mtl" competes with, supersedes, is superseded by, or is unrelated to "transformers". If "mtl" exports "monads-fd", then the latter is the case... but is that true? Which is the point.
I imagined that mtl-2 would re-export all the stuff that is currently defined in mtl, some of which is now implemented in transformers and some in monads-fd. Conrad.

Felipe Lessa
This is probably the last chance we have to deprecate the name 'mtl'. Is it doable to:
[...]
- After some time, remove mtl-2 from HP.
Or we can just rename monads-tf to mtl-2-tf.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/16/10 10:21 , Duncan Coutts wrote:
does not know what to do. It's much more work for them to discover that this new package monads-fd was just added to the platform and it seems to provide the same modules.
Wasn't the original notion to leave monads-fd as is and have mtl-2 re-export monads-fd? - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyS7roACgkQIn7hlCsL25VoxgCgxyZhQj8QKUMnFv+qOQa8bfjW h+gAn2b0BfKMClZhibHGyF7blPMylRDY =ENxn -----END PGP SIGNATURE-----

On Fri, Sep 17, 2010 at 12:29:46AM -0400, Brandon S Allbery KF8NH wrote:
On 9/16/10 10:21 , Duncan Coutts wrote:
does not know what to do. It's much more work for them to discover that this new package monads-fd was just added to the platform and it seems to provide the same modules.
Wasn't the original notion to leave monads-fd as is and have mtl-2 re-export monads-fd?
It was, but installing two packages providing modules with the same name makes problems for people using ghci or ghc --make, and the suggestion of hiding mtl was criticized as too disruptive. Hence the revised plan.

Ross Paterson wrote:
On Fri, Sep 17, 2010 at 12:29:46AM -0400, Brandon S Allbery KF8NH wrote:
On 9/16/10 10:21 , Duncan Coutts wrote:
does not know what to do. It's much more work for them to discover that this new package monads-fd was just added to the platform and it seems to provide the same modules.
Wasn't the original notion to leave monads-fd as is and have mtl-2 re-export monads-fd?
It was, but installing two packages providing modules with the same name makes problems for people using ghci or ghc --make, and the suggestion of hiding mtl was criticized as too disruptive. Hence the revised plan.
Isn't this still a problem for the things in transformers? Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Tue, Sep 21, 2010 at 12:16:08PM +0100, Sittampalam, Ganesh wrote:
Ross Paterson wrote:
On Fri, Sep 17, 2010 at 12:29:46AM -0400, Brandon S Allbery KF8NH wrote:
Wasn't the original notion to leave monads-fd as is and have mtl-2 re-export monads-fd?
It was, but installing two packages providing modules with the same name makes problems for people using ghci or ghc --make, and the suggestion of hiding mtl was criticized as too disruptive. Hence the revised plan.
Isn't this still a problem for the things in transformers?
Since transformers-0.2.0.0 there have been no module name clashes with mtl.

On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
An up to date copy of this text is kept at:
http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers
Just a minor point about the proposal. Maybe add links to the reverse dependencies of transformers and monads-fd: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/transfo... http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/monads-... or: http://sparky.haskell.org:8080/package/transformers/reverse http://sparky.haskell.org:8080/package/monads-fd/reverse Regards, Bas

On Thu, Sep 16, 2010 at 03:07:42PM +0200, Bas van Dijk wrote:
On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
wrote: Just a minor point about the proposal. Maybe add links to the reverse dependencies of transformers and monads-fd:
I've now done this. I used the sparky version, because it explains the counts.

+1
Thanks for taking the time to create this proposal. The mtl vs.
transformers issue has been bugging me for a while.
The only other comment I have:
On 16 September 2010 09:23, Ross Paterson
* simple monads are now aliases for monad trasformers applied to Identity, e.g.
newtype Reader r a = Reader { runReader :: r -> a }
is replaced by
type Reader r = ReaderT r Identity
reader :: (r -> a) -> Reader r a reader f = ReaderT (Identity . f)
runReader :: Reader r a -> r -> a runReader m = runIdentity . runReaderT m
Rationale: This avoids repetition in the interfaces of both transformers and the proposed mtl-2. It makes transformers more useful on its own, and also saves clients of mtl from defining instances for both Reader r and ReaderT r and ensuring that they are consistent.
I agree with Johan that this could be an issue. Monad transformers are known to cause performance problems while I haven't heard about serious issues with the standard monads. It's probably not that hard to get some numbers for this. / Thomas

On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
If this proposal is accepted, monads-fd would be obsoleted...
What does this mean exactly? I can see several options: 1) Don't release any new versions of monads-fd anymore. 2) Option 1 & Hiding it from the Hackage package list. 3) Releasing a new 0.1.0.3 version which indicates that it's deprecated in favor of mtl-2 It would be nice if this was clarified in the proposal. Bas

On Thu, Sep 16, 2010 at 05:33:08PM +0200, Bas van Dijk wrote:
On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
wrote: If this proposal is accepted, monads-fd would be obsoleted...
What does this mean exactly?
I can see several options:
1) Don't release any new versions of monads-fd anymore. 2) Option 1 & Hiding it from the Hackage package list. 3) Releasing a new 0.1.0.3 version which indicates that it's deprecated in favor of mtl-2
2)

On 17 September 2010 01:33, Bas van Dijk
On Thu, Sep 16, 2010 at 10:23 AM, Ross Paterson
wrote: If this proposal is accepted, monads-fd would be obsoleted...
What does this mean exactly?
I can see several options:
1) Don't release any new versions of monads-fd anymore. 2) Option 1 & Hiding it from the Hackage package list. 3) Releasing a new 0.1.0.3 version which indicates that it's deprecated in favor of mtl-2
I think 2) + 3) would work nicely, for those people that still manage to find their way tot he Hackage page and try using it (every now and then someone asks about packedstrings...). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Thu, Sep 16, 2010 at 09:23:49AM +0100, Ross Paterson wrote:
The proposal is that version 2 of the mtl package be the current contents of the monads-fd package, which depends on the transformers package:
http://hackage.haskell.org/package/monads-fd http://hackage.haskell.org/package/transformers
An up to date copy of this text is kept at:
http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers
Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages.
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
Review comments should be sent to the libraries mailing list by October 15 so that we have time to discuss and resolve issues before the final deadline on November 1.
This has been up for over 5 weeks, with no dissent (except for a proposal to obsolete mtl in favour of monads-fd). I think the next step would be to upload the tarball of mtl-2.0, which I propose to do soon.

On Mon, Oct 25, 2010 at 09:21:44AM +0100, Ross Paterson wrote:
This has been up for over 5 weeks, with no dissent (except for a proposal to obsolete mtl in favour of monads-fd).
I think the next step would be to upload the tarball of mtl-2.0, which I propose to do soon.
I uploaded mtl-2.0.0.0 to hackage last week. What is the next step on the HP side? By my reading of the procedure, it needs action from the steering committee.

On Tue, Nov 2, 2010 at 1:45 PM, Ross Paterson
On Mon, Oct 25, 2010 at 09:21:44AM +0100, Ross Paterson wrote:
This has been up for over 5 weeks, with no dissent (except for a proposal to obsolete mtl in favour of monads-fd).
I think the next step would be to upload the tarball of mtl-2.0, which I propose to do soon.
I uploaded mtl-2.0.0.0 to hackage last week.
What is the next step on the HP side? By my reading of the procedure, it needs action from the steering committee.
Wouldn't the next steps be to update all the libraries in the platform to use mtl-2? Johan

On Tue, Nov 02, 2010 at 02:10:36PM +0100, Johan Tibell wrote:
On Tue, Nov 2, 2010 at 1:45 PM, Ross Paterson
wrote: On Mon, Oct 25, 2010 at 09:21:44AM +0100, Ross Paterson wrote:
This has been up for over 5 weeks, with no dissent (except for a proposal to obsolete mtl in favour of monads-fd).
I think the next step would be to upload the tarball of mtl-2.0, which I propose to do soon.
I uploaded mtl-2.0.0.0 to hackage last week.
What is the next step on the HP side? By my reading of the procedure, it needs action from the steering committee.
Wouldn't the next steps be to update all the libraries in the platform to use mtl-2?
The ones that depend on mtl are: cgi-3001.1.7.3 (latest version 3001.1.8.1) fgl-5.4.2.3 QuickCheck-2.1.1.1 (latest version 2.3.0.2) regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.2 HTTP-4000.0.9 (latest version 4000.0.10) Assuming the latest version of HTTP is included, they all build unchanged with mtl-2.0.0.0 except for cgi-3001.1.8.1. That requires a small change to line 58 of Network/CGI/Monad.hs: instance Monad m => Functor (CGIT m) where Changing Monad to Functor will get it working with mtl >= 2, or change Monad m to (Functor m, Monad m) to work with old and new versions of mtl.

On Tue, 2 Nov 2010, Ross Paterson wrote:
That requires a small change to line 58 of Network/CGI/Monad.hs:
instance Monad m => Functor (CGIT m) where
Changing Monad to Functor will get it working with mtl >= 2, or change Monad m to (Functor m, Monad m) to work with old and new versions of mtl.
I uploaded cgi-3001.1.8.2 using (Functor m, Monad m). Anders

andersk:
On Tue, 2 Nov 2010, Ross Paterson wrote:
That requires a small change to line 58 of Network/CGI/Monad.hs:
instance Monad m => Functor (CGIT m) where
Changing Monad to Functor will get it working with mtl >= 2, or change Monad m to (Functor m, Monad m) to work with old and new versions of mtl.
I uploaded cgi-3001.1.8.2 using (Functor m, Monad m).
Note that you've added MonadCatchIO as a dependency to cgi, which is *not* part of the platform. This will prevent cgi being upgraded in the next HP release. There are three options: * propose MonadCatchIO be added to the platform, and get it accepted. * remove that dependency * merge MonadCatchIO functionality into some other package -- Don

On Tue, 2 Nov 2010, Don Stewart wrote:
Note that you've added MonadCatchIO as a dependency to cgi, which is *not* part of the platform. This will prevent cgi being upgraded in the next HP release.
Yeah, I added that in March with cgi 3001.1.8, in an effort to improve cgi’s exception handling situation [1]. Unfortunately, I learned a few weeks ago that MonadCatchIO is actually subtly broken [2], and although this problem does not affect cgi’s use of MonadCatchIO (with ReaderT and WriterT), it did throw a bit of a wrench into my plan to propose MonadCatchIO for addition to HP. In fact, I have been working on a replacement for the MonadCatchIO functionality [3], which I hope will be awesome and could eventually end up in the transformers library. I plan on uploading a package and announcing it within a day or so. But I’m not sure whether it’s realistic to expect the community to be confident in the new package before the next HP freeze, so maybe the best option for now is to backport the fix and upload a cgi 3001.1.7.4? [1] http://www.haskell.org/pipermail/libraries/2010-March/013169.html [2] http://www.haskell.org/pipermail/haskell-cafe/2010-October/084890.html [3] http://docs.yesodweb.com/blog/invertible-monads-exceptions-allocations/#disq... (see comments) Anders

On Tue, Nov 2, 2010 at 2:57 PM, Anders Kaseorg
But I’m not sure whether it’s realistic to expect the community to be confident in the new package before the next HP freeze, so maybe the best option for now is to backport the fix and upload a cgi 3001.1.7.4?
That seems the right thing to me. Moving precipitously on the CatchIO situation is a bad idea, and I look forward to a resolution of it that does the right thing on a more sound and thoughtful timescale. In the meantime, a catchIO (or invert, or morph, or whatever) instance for CGI in a separate (non-HP) package seems a reasonable solution. Cheers, Sterl.

johan.tibell:
On Tue, Nov 2, 2010 at 1:45 PM, Ross Paterson
wrote: On Mon, Oct 25, 2010 at 09:21:44AM +0100, Ross Paterson wrote:
This has been up for over 5 weeks, with no dissent (except for a proposal to obsolete mtl in favour of monads-fd).
I think the next step would be to upload the tarball of mtl-2.0, which I propose to do soon.
I uploaded mtl-2.0.0.0 to hackage last week.
What is the next step on the HP side? By my reading of the procedure, it needs action from the steering committee.
Wouldn't the next steps be to update all the libraries in the platform to use mtl-2?
Yes, I think we can get a lot of things done during BelHac this week.
participants (16)
-
Anders Kaseorg
-
Bas van Dijk
-
Brandon S Allbery KF8NH
-
Bryan O'Sullivan
-
Conrad Parker
-
Don Stewart
-
Duncan Coutts
-
Felipe Lessa
-
Henning Thielemann
-
Ivan Lazar Miljenovic
-
Johan Tibell
-
Mikhail Glushenkov
-
Ross Paterson
-
Sittampalam, Ganesh
-
Sterling Clover
-
Thomas Schilling