Re: Generalize MonadIO to MonadBase

From: Bas van Dijk
Hello,
(This should actually be a reply to the "Move MonadIO to base" thread[1] but I didn't want to break up the extremely interesting discussion on the MonadTransMorph class)
Would it be useful if we got rid of MonadIO:
class (Monad m) => MonadIO m where liftIO :: IO a -> m a
and replace it with the generalization:
class (Monad m, Monad n) => MonadBase m n | m -> n where inBase :: n a -> m a
which would allow lifting not just IO but any base monad into a stack of monad transformers.
I personally wouldn't find this particularly useful. Nearly all of my monadic programming (i.e. everything that comes to mind) uses one of three types of monads: 1. IO 2. ST 3. Monad transformers stacked on IO Lifting functions are only useful in the third case, and then I only need "lift" and "liftIO". I do like the idea and I'm not opposed to the suggestion, I just don't see a use for it myself. John

On Tue, Apr 20, 2010 at 7:26 PM, John Lato
I personally wouldn't find this particularly useful. Nearly all of my monadic programming (i.e. everything that comes to mind) uses one of three types of monads: 1. IO 2. ST
(In my case I will also add Maybe and STM).
3. Monad transformers stacked on IO
Lifting functions are only useful in the third case, and then I only need "lift" and "liftIO". I do like the idea and I'm not opposed to the suggestion, I just don't see a use for it myself.
To be honest I also never used a stack of monad transformers that had another base monad than IO. So I also don't see myself using it. However I can imagine other people will use it or are already using it (users of MonadLib for example) and I'm interested in their use-cases and experiences. regards, Bas

I haven't really been following this discussion, but I use Identity-backed monads all the time. Usually some combination of StateT, WriterT, ErrorT and ReaderT. Are there any "base" monads other than IO and Identity?

Hi, A common way to get different "base" monads is to "newtype" existing monads. Here is an example:
newtype CustomMonad a = CM (StateT Int IO a) deriving (Monad)
instance BaseM CustomMonad CustomMonad where inBase = id
... define some custom operations on CustomMonad...
The "newtype" provides an "abstraction barrier", which hides the
implementation of the CustomMonad. If you add more layers on top of
"CustomMonad" when you use "inBase" it will only lift up to
CustomMonad. This is useful if, for example, CustomMonad needs to
perform some IO actions, but for one reason or another it does not
allow for the execution of arbitrary IO computations.
Note that when you are implementing the operations of CustomMonad, you
can use "inBase" again, this time to lift all the way down to IO.
Basically, by using "newtypes", you can kind of "punctuate" a tall
tower of monads, an use "inBase" to jump from one stack to the next.
Hope that this helps,
-Iavor
On Tue, Apr 20, 2010 at 2:45 PM, Evan Laforge
I haven't really been following this discussion, but I use Identity-backed monads all the time. Usually some combination of StateT, WriterT, ErrorT and ReaderT.
Are there any "base" monads other than IO and Identity? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

This technique of newtype'ing stacks to make an abstraction barrier,
in conjuction with liftBase, seems useful to me. I can think of at
least two (related) projects where I should use it.
John
On Wed, Apr 21, 2010 at 12:21 AM, Iavor Diatchki
Hi, A common way to get different "base" monads is to "newtype" existing monads. Here is an example:
newtype CustomMonad a = CM (StateT Int IO a) deriving (Monad)
instance BaseM CustomMonad CustomMonad where inBase = id
... define some custom operations on CustomMonad...
The "newtype" provides an "abstraction barrier", which hides the implementation of the CustomMonad. If you add more layers on top of "CustomMonad" when you use "inBase" it will only lift up to CustomMonad. This is useful if, for example, CustomMonad needs to perform some IO actions, but for one reason or another it does not allow for the execution of arbitrary IO computations.
Note that when you are implementing the operations of CustomMonad, you can use "inBase" again, this time to lift all the way down to IO. Basically, by using "newtypes", you can kind of "punctuate" a tall tower of monads, an use "inBase" to jump from one stack to the next.
Hope that this helps, -Iavor
On Tue, Apr 20, 2010 at 2:45 PM, Evan Laforge
wrote: I haven't really been following this discussion, but I use Identity-backed monads all the time. Usually some combination of StateT, WriterT, ErrorT and ReaderT.
Are there any "base" monads other than IO and Identity? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Apr 20, 2010, at 17:45 , Evan Laforge wrote:
I haven't really been following this discussion, but I use Identity-backed monads all the time. Usually some combination of StateT, WriterT, ErrorT and ReaderT.
Are there any "base" monads other than IO and Identity?
ST and STM, as I understand it. All the others can be implemented as a transformer on top of Identity. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Bas van Dijk wrote:
To be honest I also never used a stack of monad transformers that had another base monad than IO. So I also don't see myself using it.
However I can imagine other people will use it or are already using it (users of MonadLib for example) and I'm interested in their use-cases and experiences.
I've used ST as a base monad a number of times. I rarely (if ever) use IO as part of a transformer stack because it has no coherent semantics and is best kept on its own. ST however gives access to mutable references and is very useful for a number of applications. ...Not that I've found the lack of liftST burdensome... -- Live well, ~wren
participants (6)
-
Bas van Dijk
-
Brandon S. Allbery KF8NH
-
Evan Laforge
-
Iavor Diatchki
-
John Lato
-
wren ng thornton