This question from John Meacham is really a Libraries Team question. Should the MonadIO class get an extra method? His case looks plausible to me. Simon -----Original Message----- From: John Meacham [mailto:john@repetae.net] Sent: 28 January 2003 06:35 To: haskell@haskell.org Subject: MonadIO needs catch? while genericizing my utility libraries to work within any MonadIO (http://haskell.cs.yale.edu/ghc/docs/latest/html/base/Control.Monad.Tran s.html) I ran into a problem, 'liftIO' is not powerful enough to catch exceptions in a MonadIO. the closest one can get is
genCatch :: MonadIO m => IO a -> (Exception -> IO a) -> m a when we want.. genCatch :: MonadIO m => m a -> (Exception -> m a) -> m a
The only way i can think of to solve this is add 'catch' (perhaps 'catchIO'? 'genCatch'?) to the MonadIO class. some open questions are whether it is possible to implement catch for any MonadIO? I would think so, since you need only store the 'internal state' of your monad at the genCatch and continue with that if an exception was raised. (this might mix badly with other extensions though?) at worst a MonadIOCatchable deriving from MonadIO could be added... John -- ------------------------------------------------------------------------ --- John Meacham - California Institute of Technology, Alum. - john@foo.net ------------------------------------------------------------------------ --- _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Simon Peyton-Jones
This question from John Meacham is really a Libraries Team question. Should the MonadIO class get an extra method? His case looks plausible to me.
And to me. If the operations only involved 'Monad', I would resist strengthening the constraint but since it involves the IO monad and exceptions are an essential part of IO (the real world often fails to behave as planned), I see no problem. The only question I see is whether it is best done by adding a superclass: class Monad m where ... class Monad m => MonadCatch m where catch :: ... class MonadCatch m => MonadIO m where liftIO :: IO a -> m a -- Alastair ps This reminds me of an observation Mark P Jones made in the Hugs source code when he implemented Haskell 1.3 IO. He pointed out a very pleasing symmetry between the success operations (>>= and return) and the failure operations (catch and fail). They have similar types and similar semantics. This symmetry just screams at you if you implement the IO monad using continuation passing (as Hugs did until last week).
On Thu, Feb 06, 2003 at 09:38:07AM -0000, Simon Peyton-Jones wrote:
This question from John Meacham is really a Libraries Team question. Should the MonadIO class get an extra method? His case looks plausible to me.
Simon
-----Original Message----- From: John Meacham [mailto:john@repetae.net] Sent: 28 January 2003 06:35 To: haskell@haskell.org Subject: MonadIO needs catch?
while genericizing my utility libraries to work within any MonadIO (http://haskell.cs.yale.edu/ghc/docs/latest/html/base/Control.Monad.Tran s.html) I ran into a problem, 'liftIO' is not powerful enough to catch exceptions in a MonadIO. the closest one can get is
genCatch :: MonadIO m => IO a -> (Exception -> IO a) -> m a when we want.. genCatch :: MonadIO m => m a -> (Exception -> m a) -> m a
The only way i can think of to solve this is add 'catch' (perhaps 'catchIO'? 'genCatch'?) to the MonadIO class.
some open questions are whether it is possible to implement catch for any MonadIO? I would think so, since you need only store the 'internal state' of your monad at the genCatch and continue with that if an exception was raised. (this might mix badly with other extensions though?) at worst a MonadIOCatchable deriving from MonadIO could be added...
Such operations should satisfy genCatch (liftIO m) (liftIO . k) = liftIO (catch m k) It's fairly straightforward to define instances for StateT, ReaderT and WriterT, but I can't think what they should be for ErrorT, ContT or ListT. (Then again, I don't think ListT IO is a monad.)
participants (3)
-
Alastair Reid -
Ross Paterson -
Simon Peyton-Jones