Re: [Haskell-cafe] Removing mtl from the Haskell Platform
Am Mittwoch, 13. Mai 2009 01:03 schrieb roconnor@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. Best wishes, Wolfgang
Am Donnerstag, den 14. Mai 2009, um 10:14 MESZ schrieb Wolfgang Jeltsch:
Am Mittwoch, 13. Mai 2009 01:03 schrieb roconnor@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
kahl@cas.mcmaster.ca wrote:
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
Many of the mtl modules do this, and I also find it irksome since it means having a list of imports which all duplicate the same "hiding (foo,bar,blatz)" annotation. Explicitly importing just the desired functions mitigates this, but it's still a bad API choice.
After all, I can use monads perferctly fine from the Prelude, but have to
import Control.Monad (liftM)
all the time anyway...
While we're on the topic ;) it'd be *really* nice if the Haskell' Prelude exported MonadPlus along with the Monad stuff (or H' equivalents). -- Live well, ~wren
kahl@cas.mcmaster.ca schrieb:
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|...).
In contrast to 'mtl', 'transformers' does not export identifiers from 'Control.Monad' or 'Control.Monad.Trans'.
participants (4)
-
Henning Thielemann -
kahl＠cas.mcmaster.ca -
Wolfgang Jeltsch -
wren ng thornton