[Haskell-cafe] Removing mtl from the Haskell Platform

[kahl at cas.mcmaster.ca]

Am Donnerstag, den 14. Mai 2009, um 10:14 MESZ schrieb Wolfgang Jeltsch:
 > 
 > Am Mittwoch, 13. Mai 2009 01:03 schrieb roconnor at theorem.ca:
 > > I wanted to pass this idea around the cafe to get some thoughts before
 > > submitting a trac on this topic.
 > >
 > > I'd like to see the mtl removed from the Haskell Platform.
 > >
 > > The mtl was a tremendous step forward when it was developed.  However, we
 > > have learned a few things about monad transformers since the development
 > > of the mtl, and it is time that we moved forward.
 > >
 > > There are at least 3 significant problem with the mtl.
 > >
 > > 1) `pass' should not be a member functions of the MonadWriter class.  It
 > > is my understanding that there is no `MonadWriter w m => MonadWriter w
 > > (ContT s m)' instance because the `pass' function cannot be implemented.
 > > I'm also highly suspicious of some other methods too (I'm looking at you
 > > `local').
 > >
 > > 2) The `StateT s (Cont r a)' instance of callCC is wrong.  The paper on
 > > modular monad transformers
 > > <http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf> describes why this is
 > > wrong.
 > >
 > > 3) I am told by many people that the order of the state and value pair in
 > > `State' is backwards.  Actually, I'm not entirely sure what the issue is
 > > here, but I trust the people who say this.
 > 
 > 4) The identifiers State and StateT are flawed. Something of value State s a 
 > doesn’t denote a state but a state transformer or however you want to name 
 > it.

5) I hardly ever use (run|exec|eval)State{T} wthout flip;
   and I just noticed that the same thing happens for runCont
   in the documentation of Control.Monad.Cont.

   I don't think that runState{T} necessarily has to be
   the field label of State{T}; I certainly have never used it as such.
   And I would tend to name the field label of State{T},
   since it is a newtype fieldlabel, ``unState{T}''.

6) I haven't been able to pinpoint it in the Haddock docs,
   but somehow Control.Monad.State re-exports Control.Monad,
   which invalidates my explicit Control.Monad imports whenever I import
   Control.Monad.State full and unqualified --- which I still do since
   only get, put, and modify appear to be named for qualified import
   and normally don't clash with other names in my modules.

   I think providing each implementation (State and StateT)
   in a separate module, and consequently renaming for qualified import
   (e.g., StateT.exec) would be desirable.

   I would not even re-export Control.Monad.Trans from
   Control.Monad.(State|Cont|...).

   After all, I can use monads perferctly fine from the Prelude,
   but have to

   import Control.Monad (liftM)

   all the time anyway... (until Monad becomes a subclass of Functor).



Best wishes,

Wolfram