MonadMorphIO [Re: Move MonadIO to base]

Anders Kaseorg andersk at MIT.EDU
Fri Apr 23 06:02:11 EDT 2010

On Wed, 14 Apr 2010, Anders Kaseorg wrote:
> class Monad m => MonadMorphIO m where
>     morphIO :: (forall b. (m a -> IO b) -> IO b) -> m a

I’d like to experimentally publish this on Hackage.  Here are some 
questions, at least a few of which should ideally have answers before I do 

• Any ideas for what it should be named?  I have to admit that I picked 
“morph” as a relatively generic word that doesn’t really mean anything.  
I wanted to call it “wrap” but discovered that MonadWrap had been taken by 
the monad-wrap package, which actually has a very similar goal but is 
slightly less general (it doesn’t support ContT).

• How should the package be split up?  If the same class to be useful with 
both mtl and transformers, one way would be to put class MonadMorphIO and 
its IO instance, class MonadTransMorph, and whatever useful functions like 
catch are wrapped with it into one package, then have two additional 
packages with instances for mtl and transformers, respectively.

• What useful functions should be wrapped with it?  Some candidates are 
catch, block, unblock (and friends from Control.Exception), forkIO, 
runInBoundThread, runInUnboundThread, unsafeInterleaveIO, withProgName, 
withArgs, alloca (and friends from Foreign.Marshal), withMVar, 
modifyMVar_, modifyMVar.  Then of course there are all the functions that 
could be wrapped with liftIO…

• Can a class like this be expressed in Haskell ’98?  (But this seems to 
be quite difficult, and I imagine we’ll be thinking about it for a while.)

• How should this relate to MonadIO?  Should MonadMorphIO eventually 
replace MonadIO entirely?  For that matter, should MonadTransMorph replace 

• Maybe I’m thinking way too far ahead, and I should just release it now 
and watch from a safe distance to see what happens?


More information about the Libraries mailing list