Version 3 (modified by ross, 5 years ago) 

Add transformers and monadstf, and base the mtl package on them
The proposal is to restructure the mtl package as a compatibility layer over new transformers and monadsfd packages. A draft of this compatibility layer is available at http://urchin.earth.li/darcs/ganesh/mtlcompat.
Proposers
 Ganesh Sittampalam (maintainer of the mtl compatibility layer)
 Ross Paterson (maintainer of transformers and monadsfd)
If this proposal is accepted, these packages would be turned over to community control (like the current mtl package).
Rationale
Monad transformers are widely used, but the MTL implementation is tied to functional dependencies, whose future is in doubt. Many people want to try out versions based on type functions, or without using advanced type classes at all, but their interfaces will then be incompatible with libraries using mtl.
The idea is to factor out the monad transformers as a Haskell 98 package, which can be used by itself or with type classes based on either functional dependencies or type functions. Interfaces referring to the monad transformers would be compatible across the different libraries.
A new version of mtl would provide a temporary almostcompatible layer over transformers + monadsfd, and clients would be encouraged (using deprecation) to switch from mtl to either plain transformers or transformers + monadsfd. However since the new and old packages use some of the same modules names, all versions of mtl would need to be hidden.
Structure
The current mtl is to be replaced with three packages.
 transformers is a Haskell 98 package containing the identity monad (Control.Monad.Identity), transformer classes (Control.Monad.Trans) and concrete monad transformers with code to lift operators (Control.Monad.Trans.*). There are also a number of changes in comparison with mtl:
 simple monads like State s are now aliases for StateT s Identity.
 Functor instances for monad transformers no longer require Monad where Functor is sufficient.
 instances of Applicative and Alternative have been added as appropriate.
The package can be used on its own (see the Control.Monad.Trans documentation for examples), or with packages adding type classes.
 monadsfd depends on transformers and adds type classes using functional dependencies. Usage is the same as the current mtl package, except for module names.
 The new version of mtl depends on transformers and monadsfd, and is almost a compatible replacement for the current version, except for the differences listed above.
Both transformers and the new mtl would expose the modules Control.Identity and Control.Monad.Trans, though the mtl versions would be reexports of the transformers modules. Thus people using ghc make would still see conflicts. Hence the new mtl would have to be deprecated and hidden. Eventually it would be removed.
Open issues
 The monadsfd and monadstf packages use the same names for modules with different interfaces. Although monadstf is not part of this proposal, should the modules in it or both the packages be renamed, and if so to what?
 Should we delete all but the Class modules from monadsfd (and monadstf)? That would mean that code using transformers and monadsfd directly would have to import both Control.Monad.Trans.State and Control.Monad.State.Class, where code using the mtl would have to import just Control.Monad.State.
 The module Control.Monad.Cont.Class is Haskell 98. Should it be moved out of monadsfd, and if so where?
 Both transformers and the new mtl would expose the modules Control.Identity and Control.Monad.Trans, though the mtl versions would be reexports of the transformers modules. Thus people using ghc make would still see conflicts.
Transition issues
A survey of Hackage in March 2009 found 19 packages that would fail to compile with the proposed new version of mtl. Note that this survey excluded packages that depend (directly or indirectly) on gtk2hs or any other packages not available on hackage. It also excluded packages that already declare an appropriate upper bound on their mtl dependency.
Those packages will need changes to compile with the new version of mtl, but need not switch to transformers and monadsfd (or just transformers) until later. These packages could add a dependency constraint mtl < 2 now, to avoid being built with the new version when it appears. The affected packages are listed below.
Different dependencies, extra instances:
 blogination: Functor instances depending on Functor, instance collision Applicative/Alternative ErrorT
 categoryextras: Functor instances depending on Functor
 cgi: Functor instances depending on Functor
 encoding: instance collision: Monad Either
 logict: instance collision: Applicative Identity (will be superfluous: same as instance in transformers)
 monadparam: Functor instances depending on Functor
 mueval: Functor instances depending on Functor
 xcbtypes: instance collision: Applicative/Alternative ReaderT (will be superfluous: same as instance in transformers; version 0.5.1.1 has mtl < 1.2)
 xmonadcontrib: instance collision: Error [a]:
Data constructors for basic monad classes:
 FileManip: Missing data constructor: State
 HAppSServer: Missing data constructor: Reader
 HaLeX: Missing data constructor: State
 LambdaHack: Missing data constructor: State (version 0.1.20090606 has mtl < 2)
 lambdabot: Missing data constructor: State
 openwitness: Missing data constructor: State
Instances for basic monad classes that are now type synonyms:
 applicativeextras: instance Applicative (State a) (will be superfluous: same as instance in transformers)
 derive: instance Applicative (Writer a) (will be superfluous: same as instance in transformers)
 randomfu: instance MonadRandom? (State StdGen?) (will be superfluous: same instance as declared for StateT)
 yhccore: instance UniqueIdM (State a) (could be trivially generalized to StateT)
Attachments

mtl2.0.0.0.tar.gz
(13.4 kB)  added by ross
5 years ago.
proposed mtl2.0.0.0.tar.gz

testSep2010
(21.3 kB)  added by ross
5 years ago.
test of mtlusing packages in Sep 2010