[Haskell-cafe] Re: Parsers are monadic?

[apfelmus]

Paul Hudak wrote:
>
>    readFile :: Name -> FailCont -> StrCont -> Behaviour
> 
> Here StrCont was the success continuation, which took a string (the file
> contents) as argument.  I rather liked the flexibility that this offered
> -- since I/O errors were fairly common, it made sense to give success
> and failure equal status.

> Claus Reinke wrote:
>> contrary to monadic parsers, those continuation-based parsers
>> had *two* continuations, one for success, one for failure. and
>> that seemed to be a very natural match for the problem.

In a sense, the MonadError class

  class Monad m => MonadError e m | m -> e where
    throwError :: e -> m a
    catchError :: m a -> (e -> m a) -> m a

defines a second monad structure, with

    return = throwError
    bind   = catchError

To make this apparent and symmetric, let's define a

  class DiMonad m where
    returnR :: a -> m e a
    bindR   :: m e a -> (a -> m e b)  -> m e b

    returnL :: e -> m e a
    bindL   :: m e a -> (e -> m e' a) -> m e' a

A dimonad  m e a  can be thought of as a monad  m e  with a variable
error type  e . The operations with suffixed by R are the "normal" monad
operations whereas the suffix L marks the "error"-catching operations.
(Question: can dimonads solve the extensible-exceptions problem?)

Now, the two-continuation approach always requires to pass two
continuations. But here, returnL and returnR only pass the failure- or
the success-continuation. To see what's happening, let's turn

  type TwoCont e a = (e -> R) -> (a -> R) -> R

with some fixed result type R into a dimonad (for clarity, we ignore
that this is only a type-synonym):

  instance DiMonad TwoCont where
    returnR x = \e a -> a x
    bindR m f = \e a -> m e (\x -> (f x) e a)

    returnL y = \e a -> e y
    bindL m f = \e a -> m (\y -> (f y) e a) a

In the case of success-continuation, this means that the dimonad passes
one and the same error continuation, i.e. one and the same
exception-handler will the thrown regardless of where the failure
happens inside a chain of actions composed with  bindR. Likewise,
error-handler and success-chain will be resumed at with a common
success-chain. Of course, this is well-known behavior for IO and
exceptions, and it seems that it reduces clutter quite well compared to
a bare TwoCont.

A final question remains: does the dimonad abstraction cover the full
power of TwoCont? I mean, it still seems like there's an operation
missing that supplies new left and right continuations at once.

Regards,
apfelmus