-- Hoogle documentation, generated by Haddock
-- See Hoogle, http://www.haskell.org/hoogle/


-- | Exceptions which are explicit in the type signature.
--   
--   Synchronous and Asynchronous exceptions which are explicit in the type
--   signature. The first ones are very similar to <a>Either</a> and
--   <a>Control.Monad.Error.ErrorT</a>. The second ones are used for
--   <a>System.IO.readFile</a> and <a>System.IO.hGetContents</a>. This
--   package is a proposal for improved exception handling in Haskell. It
--   strictly separates between handling of exceptional situations (file
--   not found, invalid user input, see
--   <a>http://www.haskell.org/haskellwiki/Exception</a>) and (programming)
--   errors (division by zero, index out of range, see
--   <a>http://www.haskell.org/haskellwiki/Error</a>). Handling of the
--   first one is called "exception handling", whereas handling of errors
--   is better known as "debugging".
--   
--   For applications see the packages <tt>midi</tt>, <tt>spreadsheet</tt>,
--   <tt>http-monad</tt>.
--   
--   Although I'm not happy with the identifier style of the Monad
--   Transformer Library (partially intended for unqualified use) I have
--   tried to adopt it for this library, in order to let Haskell
--   programmers get accustomed easily to it.
--   
--   To do: Because many people requested it, we will provide a
--   <tt>bracket</tt> function that frees a resource both when an exception
--   and an error occurs, that is, it combines exception handling and
--   debugging. However note that freeing resources in case of an error is
--   dangerous and may cause further damage.
@package explicit-exception
@version 0.1.7.1


-- | Synchronous exceptions immediately abort a series of computations. We
--   provide monads for describing this behaviour. In contrast to ErrorT
--   from <tt>mtl</tt> or <tt>transformers</tt> package we do not pose
--   restrictions on the exception type.
--   
--   How to tell, that a function can possibly throw more than one (kind
--   of) exception?
--   
--   If you would use the exception type <tt>(Either ParserException
--   IOError)</tt> then this is different from <tt>(Either IOError
--   ParserException)</tt>. Thus we recommned using type classes for
--   exceptions. Then you can use one type containing all exceptions in an
--   application, but the type signature still tells which exceptions are
--   actually possible. Examples:
--   
--   <pre>
--   parser :: ParserException e =&gt; ExceptionalT e ParserMonad a
--   
--   getLine :: IOException e =&gt; ExceptionalT e IO String
--   
--   fileParser :: (ParserException e, IOException e) =&gt; ExceptionalT e IO String
--   </pre>
--   
--   Unfortunately, this way you cannot remove single exceptions from the
--   constraints by catching them. You can only remove all of them using
--   <a>resolve</a> or none. For a more advanced approach, that allows
--   removing exceptions constraints by some non-Haskell-98 type hackery,
--   see the exception package by Joseph Iborra.
module Control.Monad.Exception.Synchronous

-- | Like <a>Either</a>, but explicitly intended for handling of
--   exceptional results. In contrast to <a>Either</a> we do not support
--   <a>fail</a>. Calling <a>fail</a> in the <a>Exceptional</a> monad is an
--   error. This way, we do not require that an exception can be derived
--   from a <a>String</a>, yet, we require no constraint on the exception
--   type at all.
data Exceptional e a
Success :: a -> Exceptional e a
Exception :: e -> Exceptional e a
fromMaybe :: e -> Maybe a -> Exceptional e a
toMaybe :: Exceptional e a -> Maybe a
fromEither :: Either e a -> Exceptional e a
toEither :: Exceptional e a -> Either e a
fromExitCode :: ExitCode -> Exceptional Int ()
toExitCode :: Exceptional Int () -> ExitCode

-- | useful in connection with <a>continue</a>
getExceptionNull :: Exceptional e () -> Maybe e

-- | Counterpart to <a>either</a> for <a>Either</a>.
switch :: (e -> b) -> (a -> b) -> Exceptional e a -> b

-- | If you are sure that the value is always a <a>Success</a> you can tell
--   that the run-time system thus making your program lazy. However, try
--   to avoid this function by using <a>catch</a> and friends, since this
--   function is partial.
force :: Exceptional e a -> Exceptional e a
mapException :: (e0 -> e1) -> Exceptional e0 a -> Exceptional e1 a
mapExceptional :: (e0 -> e1) -> (a -> b) -> Exceptional e0 a -> Exceptional e1 b
throw :: e -> Exceptional e a
assert :: e -> Bool -> Exceptional e ()
catch :: Exceptional e0 a -> (e0 -> Exceptional e1 a) -> Exceptional e1 a
resolve :: (e -> a) -> Exceptional e a -> a

-- | see <a>mergeT</a>
merge :: Monoid e => Exceptional e (a -> b) -> Exceptional e a -> Exceptional e b

-- | like ErrorT, but ExceptionalT is the better name in order to
--   distinguish from real (programming) errors
newtype ExceptionalT e m a
ExceptionalT :: m (Exceptional e a) -> ExceptionalT e m a
runExceptionalT :: ExceptionalT e m a -> m (Exceptional e a)
fromMaybeT :: Monad m => e -> MaybeT m a -> ExceptionalT e m a
toMaybeT :: Monad m => ExceptionalT e m a -> MaybeT m a
fromErrorT :: Monad m => ErrorT e m a -> ExceptionalT e m a
toErrorT :: Monad m => ExceptionalT e m a -> ErrorT e m a
fromEitherT :: Monad m => m (Either e a) -> ExceptionalT e m a
toEitherT :: Monad m => ExceptionalT e m a -> m (Either e a)
fromExitCodeT :: Functor m => m ExitCode -> ExceptionalT Int m ()
toExitCodeT :: Functor m => ExceptionalT Int m () -> m ExitCode
switchT :: Monad m => (e -> m b) -> (a -> m b) -> ExceptionalT e m a -> m b

-- | see <a>force</a>
forceT :: Monad m => ExceptionalT e m a -> ExceptionalT e m a
mapExceptionT :: Monad m => (e0 -> e1) -> ExceptionalT e0 m a -> ExceptionalT e1 m a
mapExceptionalT :: (m (Exceptional e0 a) -> n (Exceptional e1 b)) -> ExceptionalT e0 m a -> ExceptionalT e1 n b
throwT :: Monad m => e -> ExceptionalT e m a
assertT :: Monad m => e -> Bool -> ExceptionalT e m ()
catchT :: Monad m => ExceptionalT e0 m a -> (e0 -> ExceptionalT e1 m a) -> ExceptionalT e1 m a

-- | If the enclosed monad has custom exception facilities, they could skip
--   the cleanup code. Make sure, that this cannot happen by choosing an
--   appropriate monad.
bracketT :: Monad m => ExceptionalT e m h -> (h -> ExceptionalT e m ()) -> (h -> ExceptionalT e m a) -> ExceptionalT e m a
resolveT :: Monad m => (e -> m a) -> ExceptionalT e m a -> m a
tryT :: Monad m => ExceptionalT e m a -> m (Exceptional e a)

-- | Repeat an action until an exception occurs. Initialize the result with
--   <tt>empty</tt> and add new elements using <tt>cons</tt> (e.g.
--   <tt>[]</tt> and <tt>(:)</tt>). The exception handler decides whether
--   the terminating exception is re-raised (<a>Just</a>) or catched
--   (<a>Nothing</a>).
manyT :: Monad m => (e0 -> Maybe e1) -> (a -> b -> b) -> b -> ExceptionalT e0 m a -> ExceptionalT e1 m b
manyMonoidT :: (Monad m, Monoid a) => (e0 -> Maybe e1) -> ExceptionalT e0 m a -> ExceptionalT e1 m a

-- | This combines two actions similar to Applicative's <tt><a>*</a></tt>.
--   The result action fails if one of the input action fails, but both
--   actions are executed. E.g. consider a compiler that emits all errors
--   that can be detected independently, but eventually aborts if there is
--   at least one error.
--   
--   The exception type <tt>e</tt> might be a list type, or an
--   <tt>Endo</tt> type that implements a difflist.
mergeT :: (Monoid e, Monad m) => ExceptionalT e m (a -> b) -> ExceptionalT e m a -> ExceptionalT e m b
instance (Show e, Show a) => Show (Exceptional e a)
instance (Eq e, Eq a) => Eq (Exceptional e a)
instance MonadTrans (ExceptionalT e)
instance MonadFix m => MonadFix (ExceptionalT e m)
instance Monad m => Monad (ExceptionalT e m)
instance Applicative m => Applicative (ExceptionalT e m)
instance Functor m => Functor (ExceptionalT e m)
instance MonadFix (Exceptional e)
instance Monad (Exceptional e)
instance Applicative (Exceptional e)
instance Functor (Exceptional e)

module Control.Monad.Exception.Asynchronous.Strict

-- | Contains a value and a reason why the computation of the value of type
--   <tt>a</tt> was terminated. Imagine <tt>a</tt> as a list type, and an
--   according operation like the <a>readFile</a> operation. If the
--   exception part is <a>Nothing</a> then the value could be constructed
--   regularly. If the exception part is <a>Just</a> then the value could
--   not be constructed completely. However you can read the result of type
--   <tt>a</tt> lazily, even if an exception occurs while it is evaluated.
--   If you evaluate the exception part, then the result value is certainly
--   computed completely.
--   
--   However, we cannot provide general <a>Monad</a> functionality due to
--   the very different ways of combining the results of type <tt>a</tt>.
--   It is recommended to process the result value in an application
--   specific way, and after consumption of the result, throw a synchronous
--   exception using <a>toSynchronous</a>.
--   
--   Maybe in the future we provide a monad instance which considers
--   subsequent actions as simultaneous processes on a lazy data structure.
data Exceptional e a
Exceptional :: Maybe e -> a -> Exceptional e a
exception :: Exceptional e a -> Maybe e
result :: Exceptional e a -> a

-- | Create an exceptional value without exception.
pure :: a -> Exceptional e a

-- | Create an exceptional value with exception.
broken :: e -> a -> Exceptional e a
fromSynchronous :: a -> Exceptional e a -> Exceptional e a
fromSynchronousNull :: Exceptional e () -> Exceptional e ()
fromSynchronousMonoid :: Monoid a => Exceptional e a -> Exceptional e a
toSynchronous :: Exceptional e a -> Exceptional e a

-- | I think in most cases we want throwMonoid, thus we can replace
--   <a>throw</a> by <a>throwMonoid</a>.
throw :: e -> Exceptional e ()
throwMonoid :: Monoid a => e -> Exceptional e a

-- | You might use an exception of type <tt>Maybe e</tt> in
--   <a>manyMonoidT</a> in order to stop the loop. After finishing the loop
--   you will want to turn the <tt>Nothing</tt> exception into a success.
--   This is achieved by this function.
eatNothing :: Exceptional (Maybe e) a -> Exceptional e a

-- | This is an example for application specific handling of result values.
--   Assume you obtain two lazy lists say from <a>readFile</a> and you want
--   to zip their contents. If one of the stream readers emits an
--   exception, we quit with that exception. If both streams have throw an
--   exception at the same file position, the exception of the first stream
--   is propagated.
zipWith :: (a -> b -> c) -> Exceptional e [a] -> Exceptional e [b] -> Exceptional e [c]

-- | This is an example for application specific handling of result values.
--   Assume you obtain two lazy lists say from <a>readFile</a> and you want
--   to append their contents. If the first stream ends with an exception,
--   this exception is kept and the second stream is not touched. If the
--   first stream can be read successfully, the second one is appended
--   until stops.
--   
--   <a>append</a> is less strict than the <a>Monoid</a> method
--   <a>mappend</a> instance.
append :: Monoid a => Exceptional e a -> Exceptional e a -> Exceptional e a
continue :: Monoid a => Maybe e -> Exceptional e a -> Exceptional e a
maybeAbort :: Exceptional e a -> Maybe e -> Exceptional e a

-- | construct Exceptional constructor lazily
force :: Exceptional e a -> Exceptional e a
mapException :: (e0 -> e1) -> Exceptional e0 a -> Exceptional e1 a
mapExceptional :: (e0 -> e1) -> (a -> b) -> Exceptional e0 a -> Exceptional e1 b

-- | I consider both actions to process the data simultaneously through
--   lazy evaluation. If the second one fails too, it must have encountered
--   an exception in the data that was successfully emitted by the first
--   action, and thus the exception of the second action is probably
--   earlier.
--   
--   We cannot check in general whether the two exception occur at the same
--   time, e.g. the second one might occur since the first occured and left
--   an invalid structure. In this case we should emit the first exception,
--   not the second one. Because of this I expect that this function is not
--   particularly useful. Otherwise it could be used as bind operation for
--   a monad instance.

-- | <i>Deprecated: Check whether this function is really what you need. It
--   generates an unreasonable exception when the second exception is
--   caused by the first one. </i>
simultaneousBind :: Exceptional e a -> (a -> Exceptional e b) -> Exceptional e b

-- | <i>Deprecated: Check whether this function is really what you need. It
--   generates an unreasonable exception when the second exception is
--   caused by the first one. </i>
simultaneousBindM :: Monad m => m (Exceptional e a) -> (a -> m (Exceptional e b)) -> m (Exceptional e b)

-- | Is there a better name?
sequenceF :: Functor f => Exceptional e (f a) -> f (Exceptional e a)

-- | <tt>Foldable</tt> instance would allow to strip off the exception too
--   easily.
--   
--   I like the methods of <tt>Traversable</tt>, but <tt>Traversable</tt>
--   instance requires <tt>Foldable</tt> instance.
traverse :: Applicative f => (a -> f b) -> Exceptional e a -> f (Exceptional e b)
sequenceA :: Applicative f => Exceptional e (f a) -> f (Exceptional e a)
mapM :: Monad m => (a -> m b) -> Exceptional e a -> m (Exceptional e b)
sequence :: Monad m => Exceptional e (m a) -> m (Exceptional e a)

-- | Consider a file format consisting of a header and a data body. The
--   header can only be used if is read completely. Its parsing might stop
--   with an synchronous exception. The data body can also be used if it is
--   truncated by an exceptional event. This is expressed by an
--   asynchronous exception. A loader for this file format can thus fail by
--   a synchronous and an asynchronous exception. Surprisingly, both orders
--   of nesting these two kinds of exceptional actions are equally
--   expressive. This function converts to the form where the synchronous
--   exception is the outer one.
--   
--   This is a specialisation of <a>sequence</a> and friends.
swapToSynchronousAsynchronous :: Exceptional e0 (Exceptional e1 a) -> Exceptional e1 (Exceptional e0 a)
swapToAsynchronousSynchronous :: Exceptional e1 (Exceptional e0 a) -> Exceptional e0 (Exceptional e1 a)

-- | In contrast to synchronous exceptions, the asynchronous monad
--   transformer is not quite a monad. You must use the <a>Monoid</a>
--   interface or <a>bindT</a> instead.
newtype ExceptionalT e m a
ExceptionalT :: m (Exceptional e a) -> ExceptionalT e m a
runExceptionalT :: ExceptionalT e m a -> m (Exceptional e a)
fromSynchronousT :: Functor m => a -> ExceptionalT e m a -> ExceptionalT e m a
fromSynchronousMonoidT :: (Functor m, Monoid a) => ExceptionalT e m a -> ExceptionalT e m a

-- | see <a>force</a>
forceT :: Monad m => ExceptionalT e m a -> ExceptionalT e m a
mapExceptionT :: Monad m => (e0 -> e1) -> ExceptionalT e0 m a -> ExceptionalT e1 m a
mapExceptionalT :: (m (Exceptional e0 a) -> n (Exceptional e1 b)) -> ExceptionalT e0 m a -> ExceptionalT e1 n b
throwMonoidT :: (Monad m, Monoid a) => e -> ExceptionalT e m a
eatNothingT :: Monad m => ExceptionalT (Maybe e) m a -> ExceptionalT e m a

-- | The monadic bind operation. It cannot be made an instance of the Monad
--   class method <tt>(&gt;&gt;=)</tt> since it requires a default return
--   value in case the first action fails. We get this default value by the
--   <a>Monoid</a> method <a>mempty</a>.
bindT :: (Monad m, Monoid b) => ExceptionalT e m a -> (a -> ExceptionalT e m b) -> ExceptionalT e m b

-- | Repeat an action with synchronous exceptions until an exception
--   occurs. Combine all atomic results using the <tt>bind</tt> function.
--   It may be <tt>cons = (:)</tt> and <tt>empty = []</tt> for <tt>b</tt>
--   being a list type. The <tt>defer</tt> function may be <tt>id</tt> or
--   <tt>unsafeInterleaveIO</tt> for lazy read operations. The exception is
--   returned as asynchronous exception.

-- | <i>Deprecated: use manyMonoidT with appropriate Monad like LazyIO and
--   result Monoid like Endo instead </i>
manySynchronousT :: Monad m => (m (Exceptional e b) -> m (Exceptional e b)) -> (a -> b -> b) -> b -> ExceptionalT e m a -> m (Exceptional e b)

-- | We advise to use the Endo Monoid when you want to read a series of
--   characters into a list. This means you use the difference lists
--   technique in order to build the list, which is efficient.
--   
--   <pre>
--   import Data.Monoid (Endo, appEndo, )
--   import Control.Exception (try, )
--   import qualified Control.Monad.Exception.Synchronous as Sync
--   </pre>
--   
--   <pre>
--   fmap (flip appEndo []) $ manyMonoidT (fromSynchronousMonoidT $ fmap (Endo . (:)) $ Sync.fromEitherT $ try getChar)
--   </pre>
--   
--   If you want Lazy IO you must additionally convert <tt>getChar</tt> to
--   LazyIO monad.
manyMonoidT :: (Monad m, Monoid a) => ExceptionalT e m a -> ExceptionalT e m a

-- | Scan <tt>x</tt> using the <tt>decons</tt> function and run an action
--   with synchronous exceptions for each element fetched from <tt>x</tt>.
--   Each invocation of an element action may stop this function due to an
--   exception. If all element actions can be performed successfully and if
--   there is an asynchronous exception then at the end this exception is
--   raised as synchronous exception. <tt>decons</tt> function might be
--   <tt>Data.List.HT.viewL</tt>.
processToSynchronousT_ :: Monad m => (b -> Maybe (a, b)) -> (a -> ExceptionalT e m ()) -> Exceptional e b -> ExceptionalT e m ()
appendM :: (Monad m, Monoid a) => m (Exceptional e a) -> m (Exceptional e a) -> m (Exceptional e a)
continueM :: (Monad m, Monoid a) => m (Maybe e) -> m (Exceptional e a) -> m (Exceptional e a)
instance (Show e, Show a) => Show (Exceptional e a)
instance (Monad m, Monoid a) => Monoid (ExceptionalT e m a)
instance Functor m => Functor (ExceptionalT e m)
instance Functor (Exceptional e)
instance Monoid a => Monoid (Exceptional e a)

module Control.Monad.Exception.Asynchronous.Lazy

-- | Contains a value and a reason why the computation of the value of type
--   <tt>a</tt> was terminated. Imagine <tt>a</tt> as a list type, and an
--   according operation like the <a>readFile</a> operation. If the
--   exception part is <a>Nothing</a> then the value could be constructed
--   regularly. If the exception part is <a>Just</a> then the value could
--   not be constructed completely. However you can read the result of type
--   <tt>a</tt> lazily, even if an exception occurs while it is evaluated.
--   If you evaluate the exception part, then the result value is certainly
--   computed completely.
--   
--   However, we cannot provide general <a>Monad</a> functionality due to
--   the very different ways of combining the results of type <tt>a</tt>.
--   It is recommended to process the result value in an application
--   specific way, and after consumption of the result, throw a synchronous
--   exception using <a>toSynchronous</a>.
--   
--   Maybe in the future we provide a monad instance which considers
--   subsequent actions as simultaneous processes on a lazy data structure.
--   
--   This variant has lazy combinators like <a>fmap</a>. This implies that
--   some laws are not fulfilled, but in practice it saves you some calls
--   to <a>force</a>.
data Exceptional e a
Exceptional :: Maybe e -> a -> Exceptional e a
exception :: Exceptional e a -> Maybe e
result :: Exceptional e a -> a

-- | Create an exceptional value without exception.
pure :: a -> Exceptional e a

-- | Create an exceptional value with exception.
broken :: e -> a -> Exceptional e a
fromSynchronous :: a -> Exceptional e a -> Exceptional e a
fromSynchronousNull :: Exceptional e () -> Exceptional e ()
fromSynchronousMonoid :: Monoid a => Exceptional e a -> Exceptional e a
toSynchronous :: Exceptional e a -> Exceptional e a

-- | I think in most cases we want throwMonoid, thus we can replace
--   <a>throw</a> by <a>throwMonoid</a>.
throw :: e -> Exceptional e ()
throwMonoid :: Monoid a => e -> Exceptional e a

-- | You might use an exception of type <tt>Maybe e</tt> in
--   <a>manyMonoidT</a> in order to stop the loop. After finishing the loop
--   you will want to turn the <tt>Nothing</tt> exception into a success.
--   This is achieved by this function.
eatNothing :: Exceptional (Maybe e) a -> Exceptional e a

-- | This is an example for application specific handling of result values.
--   Assume you obtain two lazy lists say from <a>readFile</a> and you want
--   to zip their contents. If one of the stream readers emits an
--   exception, we quit with that exception. If both streams have throw an
--   exception at the same file position, the exception of the first stream
--   is propagated.
zipWith :: (a -> b -> c) -> Exceptional e [a] -> Exceptional e [b] -> Exceptional e [c]

-- | This is an example for application specific handling of result values.
--   Assume you obtain two lazy lists say from <a>readFile</a> and you want
--   to append their contents. If the first stream ends with an exception,
--   this exception is kept and the second stream is not touched. If the
--   first stream can be read successfully, the second one is appended
--   until stops.
--   
--   <a>append</a> is less strict than the <a>Monoid</a> method
--   <a>mappend</a> instance.
append :: Monoid a => Exceptional e a -> Exceptional e a -> Exceptional e a
continue :: Monoid a => Maybe e -> Exceptional e a -> Exceptional e a
maybeAbort :: Exceptional e a -> Maybe e -> Exceptional e a

-- | construct Exceptional constructor lazily
force :: Exceptional e a -> Exceptional e a
mapException :: (e0 -> e1) -> Exceptional e0 a -> Exceptional e1 a
mapExceptional :: (e0 -> e1) -> (a -> b) -> Exceptional e0 a -> Exceptional e1 b

-- | I consider both actions to process the data simultaneously through
--   lazy evaluation. If the second one fails too, it must have encountered
--   an exception in the data that was successfully emitted by the first
--   action, and thus the exception of the second action is probably
--   earlier.
--   
--   We cannot check in general whether the two exception occur at the same
--   time, e.g. the second one might occur since the first occured and left
--   an invalid structure. In this case we should emit the first exception,
--   not the second one. Because of this I expect that this function is not
--   particularly useful. Otherwise it could be used as bind operation for
--   a monad instance.

-- | <i>Deprecated: Check whether this function is really what you need. It
--   generates an unreasonable exception when the second exception is
--   caused by the first one. </i>
simultaneousBind :: Exceptional e a -> (a -> Exceptional e b) -> Exceptional e b

-- | <i>Deprecated: Check whether this function is really what you need. It
--   generates an unreasonable exception when the second exception is
--   caused by the first one. </i>
simultaneousBindM :: Monad m => m (Exceptional e a) -> (a -> m (Exceptional e b)) -> m (Exceptional e b)

-- | Is there a better name?
sequenceF :: Functor f => Exceptional e (f a) -> f (Exceptional e a)

-- | <tt>Foldable</tt> instance would allow to strip off the exception too
--   easily.
--   
--   I like the methods of <tt>Traversable</tt>, but <tt>Traversable</tt>
--   instance requires <tt>Foldable</tt> instance.
traverse :: Applicative f => (a -> f b) -> Exceptional e a -> f (Exceptional e b)
sequenceA :: Applicative f => Exceptional e (f a) -> f (Exceptional e a)
mapM :: Monad m => (a -> m b) -> Exceptional e a -> m (Exceptional e b)
sequence :: Monad m => Exceptional e (m a) -> m (Exceptional e a)

-- | Consider a file format consisting of a header and a data body. The
--   header can only be used if is read completely. Its parsing might stop
--   with an synchronous exception. The data body can also be used if it is
--   truncated by an exceptional event. This is expressed by an
--   asynchronous exception. A loader for this file format can thus fail by
--   a synchronous and an asynchronous exception. Surprisingly, both orders
--   of nesting these two kinds of exceptional actions are equally
--   expressive. This function converts to the form where the synchronous
--   exception is the outer one.
--   
--   This is a specialisation of <a>sequence</a> and friends.
swapToSynchronousAsynchronous :: Exceptional e0 (Exceptional e1 a) -> Exceptional e1 (Exceptional e0 a)
swapToAsynchronousSynchronous :: Exceptional e1 (Exceptional e0 a) -> Exceptional e0 (Exceptional e1 a)

-- | In contrast to synchronous exceptions, the asynchronous monad
--   transformer is not quite a monad. You must use the <a>Monoid</a>
--   interface or <a>bindT</a> instead.
newtype ExceptionalT e m a
ExceptionalT :: m (Exceptional e a) -> ExceptionalT e m a
runExceptionalT :: ExceptionalT e m a -> m (Exceptional e a)
fromSynchronousT :: Functor m => a -> ExceptionalT e m a -> ExceptionalT e m a
fromSynchronousMonoidT :: (Functor m, Monoid a) => ExceptionalT e m a -> ExceptionalT e m a

-- | see <a>force</a>
forceT :: Monad m => ExceptionalT e m a -> ExceptionalT e m a
mapExceptionT :: Monad m => (e0 -> e1) -> ExceptionalT e0 m a -> ExceptionalT e1 m a
mapExceptionalT :: (m (Exceptional e0 a) -> n (Exceptional e1 b)) -> ExceptionalT e0 m a -> ExceptionalT e1 n b
throwMonoidT :: (Monad m, Monoid a) => e -> ExceptionalT e m a
eatNothingT :: Monad m => ExceptionalT (Maybe e) m a -> ExceptionalT e m a

-- | The monadic bind operation. It cannot be made an instance of the Monad
--   class method <tt>(&gt;&gt;=)</tt> since it requires a default return
--   value in case the first action fails. We get this default value by the
--   <a>Monoid</a> method <a>mempty</a>.
bindT :: (Monad m, Monoid b) => ExceptionalT e m a -> (a -> ExceptionalT e m b) -> ExceptionalT e m b

-- | Repeat an action with synchronous exceptions until an exception
--   occurs. Combine all atomic results using the <tt>bind</tt> function.
--   It may be <tt>cons = (:)</tt> and <tt>empty = []</tt> for <tt>b</tt>
--   being a list type. The <tt>defer</tt> function may be <tt>id</tt> or
--   <tt>unsafeInterleaveIO</tt> for lazy read operations. The exception is
--   returned as asynchronous exception.

-- | <i>Deprecated: use manyMonoidT with appropriate Monad like LazyIO and
--   result Monoid like Endo instead </i>
manySynchronousT :: Monad m => (m (Exceptional e b) -> m (Exceptional e b)) -> (a -> b -> b) -> b -> ExceptionalT e m a -> m (Exceptional e b)

-- | We advise to use the Endo Monoid when you want to read a series of
--   characters into a list. This means you use the difference lists
--   technique in order to build the list, which is efficient.
--   
--   <pre>
--   import Data.Monoid (Endo, appEndo, )
--   import Control.Exception (try, )
--   import qualified Control.Monad.Exception.Synchronous as Sync
--   </pre>
--   
--   <pre>
--   fmap (flip appEndo []) $ manyMonoidT (fromSynchronousMonoidT $ fmap (Endo . (:)) $ Sync.fromEitherT $ try getChar)
--   </pre>
--   
--   If you want Lazy IO you must additionally convert <tt>getChar</tt> to
--   LazyIO monad.
manyMonoidT :: (Monad m, Monoid a) => ExceptionalT e m a -> ExceptionalT e m a

-- | Scan <tt>x</tt> using the <tt>decons</tt> function and run an action
--   with synchronous exceptions for each element fetched from <tt>x</tt>.
--   Each invocation of an element action may stop this function due to an
--   exception. If all element actions can be performed successfully and if
--   there is an asynchronous exception then at the end this exception is
--   raised as synchronous exception. <tt>decons</tt> function might be
--   <tt>Data.List.HT.viewL</tt>.
processToSynchronousT_ :: Monad m => (b -> Maybe (a, b)) -> (a -> ExceptionalT e m ()) -> Exceptional e b -> ExceptionalT e m ()
appendM :: (Monad m, Monoid a) => m (Exceptional e a) -> m (Exceptional e a) -> m (Exceptional e a)
continueM :: (Monad m, Monoid a) => m (Maybe e) -> m (Exceptional e a) -> m (Exceptional e a)
instance (Show e, Show a) => Show (Exceptional e a)
instance (Monad m, Monoid a) => Monoid (ExceptionalT e m a)
instance Functor m => Functor (ExceptionalT e m)
instance Functor (Exceptional e)
instance Monoid a => Monoid (Exceptional e a)


-- | Asynchronous exceptions can occur during the construction of a lazy
--   data structure. They are represented by a lazy data structure itself.
--   
--   This module re-exports the type with lazy combinators.
--   
--   TODO:
--   
--   <ul>
--   <li>Is the Null type appropriate anywhere? Should it be better a
--   Monoid type with mempty? Shall Monoid.mempty be the default, or
--   functions with explicit default values?</li>
--   <li>Shall we replace Monad constraint by Functor constraint, where we
--   only need liftM?</li>
--   </ul>
module Control.Monad.Exception.Asynchronous
