MonadMorphIO [Re: Move MonadIO to base]
Heinrich Apfelmus
apfelmus at quantentunnel.de
Fri Apr 23 07:05:11 EDT 2010
Anders Kaseorg wrote:
> 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
> so:
>
> • 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 about renaming morph to liftControl ? This makes it explicit
that the point is to lift control operators.
> • 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…
I think it's best to wrap just a few functions like catch and forkIO
and then thoroughly document how to lift your own.
> • How should this relate to MonadIO? Should MonadMorphIO eventually
> replace MonadIO entirely? For that matter, should MonadTransMorph replace
> MonadTrans?
It cannot be a replacement because MonadTransMorph is strictly more
powerful than MonadTrans (same for IO): not every instance of
MonadTrans can also be an instance of MonadTransMorph. This is why I
suspect there could be something wrong with the ContT instance. Hard to
tell without having a clear specification of what should be right.
> • 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?
A little thought can never hurt. ;)
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
More information about the Libraries
mailing list