MonadIO in mtl and transformers

Folks, Would there be support for splitting off the MonadIO class from the mtl, and simple having Control.Monad.Trans re-export it? My proposed packaging of the functionality is here: http://community.haskell.org/~aslatter/code/monad-io Here's my problem which prompted this: I'm converting a library of mine over to the failure[1] package for returning errors, and the type on a lot of my functions is as follows: (MonadFailure MyFailureType m, MonadIO m) => Alpha -> Beta -> m Gamma The MonadFailure constraint is defined separate from its many instances, which would give the consumers of my library the choice between using the mtl or the transformers[2] library. Except that I also need a MonadIO constraint, for which I must pick from which package I choose it. Antoine [1] http://hackage.haskell.org/package/failure

On Mon, Dec 21, 2009 at 4:10 AM, Antoine Latter
Folks,
Would there be support for splitting off the MonadIO class from the mtl, and simple having Control.Monad.Trans re-export it? My proposed packaging of the functionality is here: http://community.haskell.org/~aslatter/code/monad-iohttp://community.haskell.org/%7Easlatter/code/monad-io
Here's my problem which prompted this:
I'm converting a library of mine over to the failure[1] package for returning errors, and the type on a lot of my functions is as follows:
(MonadFailure MyFailureType m, MonadIO m) => Alpha -> Beta -> m Gamma
The MonadFailure constraint is defined separate from its many instances, which would give the consumers of my library the choice between using the mtl or the transformers[2] library.
Except that I also need a MonadIO constraint, for which I must pick from which package I choose it.
Antoine
[1] http://hackage.haskell.org/package/failure _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1, this is a great idea. I've had to purposely remove useful functions from safe-failure package due to this issue as well. I think we all agree that the best choice is to merge mtl and transformers, but since that discussion seems to have come to a stand-still, splitting off MonadIO and MonadTrans seems like a good second best. Of course, I won't complain if someone just fixes the mtl/transformers mess itself ;). Michael

On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman
Of course, I won't complain if someone just fixes the mtl/transformers mess itself ;).
Yes, that's the other valid solution. My request has been documented on GHC Trac in bug 3777: http://hackage.haskell.org/trac/ghc/ticket/3777 Antoine

On Mon, Dec 21, 2009 at 7:47 AM, Antoine Latter
On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman
wrote: Of course, I won't complain if someone just fixes the mtl/transformers
mess
itself ;).
Yes, that's the other valid solution.
My request has been documented on GHC Trac in bug 3777: http://hackage.haskell.org/trac/ghc/ticket/3777
Antoine
Is there any reason to export only MonadIO? MonadTrans seems like a good candidate for that split as well. Michael

On Mon, Dec 21, 2009 at 12:27 AM, Michael Snoyman
On Mon, Dec 21, 2009 at 7:47 AM, Antoine Latter
wrote: On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman
wrote: Of course, I won't complain if someone just fixes the mtl/transformers mess itself ;).
Yes, that's the other valid solution.
My request has been documented on GHC Trac in bug 3777: http://hackage.haskell.org/trac/ghc/ticket/3777
Antoine
Is there any reason to export only MonadIO? MonadTrans seems like a good candidate for that split as well.
Michael
I guess I've never need the 'lift' function outside of code which used other bits of the mtl, so I did not export it. I'm struggling to come up with a concept which would unify a package containing both the MonadIO class and the MonadTrans class. The mtl made sense, as it contained shed-loads of other classes. Antoine

Antoine Latter wrote:
Michael Snoyman wrote:
Is there any reason to export only MonadIO? MonadTrans seems like a good candidate for that split as well.
I guess I've never need the 'lift' function outside of code which used other bits of the mtl, so I did not export it.
I'm struggling to come up with a concept which would unify a package containing both the MonadIO class and the MonadTrans class. The mtl made sense, as it contained shed-loads of other classes.
Maybe it'd be worth just rolling into base, instead of a separate package? Both MonadTrans and MonadIO seem as basic to me as MonadPlus. And I don't recall there ever being controversy about the design of either class. (Moving them to base may mess up folks using new base + old mtl ...but that seems fixable by forcing old+old or new+new.) -- Live well, ~wren

On Mon, Dec 21, 2009 at 12:09 PM, wren ng thornton < wren@community.haskell.org> wrote:
Antoine Latter wrote:
Michael Snoyman wrote:
Is there any reason to export only MonadIO? MonadTrans seems like a good candidate for that split as well.
I guess I've never need the 'lift' function outside of code which used other bits of the mtl, so I did not export it.
I'm struggling to come up with a concept which would unify a package containing both the MonadIO class and the MonadTrans class. The mtl made sense, as it contained shed-loads of other classes.
Maybe it'd be worth just rolling into base, instead of a separate package? Both MonadTrans and MonadIO seem as basic to me as MonadPlus. And I don't recall there ever being controversy about the design of either class. (Moving them to base may mess up folks using new base + old mtl ...but that seems fixable by forcing old+old or new+new.)
-- Live well, ~wren
By the way, does anyone have an update on where we stand wrt the mtl/transformers situation?
Michael
participants (3)
-
Antoine Latter
-
Michael Snoyman
-
wren ng thornton