[Haskell-cafe] Parsers are monadic?

[Claus Reinke]

>> 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.
>
>Two-continuations is a monad too, right?

yes, but my problem is not about giving them a monadic interface,
but about getting more advantages than disadvantages out of that.
the initial definitions are more complicated than using continuations
directly, and usually, the monadic interface forces me to interleave 
handling of the two paths into a single thread of specifications. 

and while instances of the monadic combinators can be defined to 
thread information for both continuations, i still have to inject that
information outside the monadic interface, and make sure that it
doesn't get reset to nothing just because someone calls Monad
fail (via a library function or pattern-match failure), or MonadPlus 
mzero (via things like guard).

a second problem is that some of the advantages of monadic 
interfaces that i tend to rely on heavily, such as pattern-match
failure handling in do-notation, are hardwired to the wrong part
of the monadic interface (Monad fail). this is not something a 
non-monadic approach would offer any help with, though..

> instance Monad m => Monad (ContErrorT m) where ..
> instance Monad m => MonadError Exception (ContErrorT m) where ..
>
> Am I missing something really obvious here?

interesting. i tend to use Monad/MonadPlus for sequence/
alternative, rather than Monad/MonadError, but you're right: 
MonadError's method types are a more natural dual to Monad's.
they don't have to be limited to Exception, either.

it seems i should be using that class more. actually, i am using
that class, via the ErrorT transformer, but i guess i thought of 
MonadError only as error handling in sequences (which is the
way it is usually presented) rather than as fallthrough in alternatives.

it would force me to decide in advance whether i want fallthrough 
branches (MonadError) or collections of alternatives (MonadPlus), 
whereas MonadPlus allowed me to delay that decision (using 
MonadPlus Maybe for fallthrough or MonadPlus [] for collections, 
for instance). hmm, perhaps one can abstract over that decision.

now, if we could replace calls to Monad fail (especially, pattern
match failure in do-notation) with calls to MonadError throwError,
we might actually be getting somewhere (similarly, we'd need to
replace MonadPlus-based guard with a MonadError-based 
variant). as a start, 

    fail msg = throwError (PatternMatchError msg)

isn't too far off, but it would be lying for fail called from library 
functions, not to mention that it would still be limited to Strings.
but i've already used my own variant of catchError to limit
information loss and preserve the most specific error message,
so once again, MonadError seems a natural fit.

all in all, your answer only strengthens my view that monadic
programming would be more symmetric if we always had two
continuations, one for failure, one for success. then do-notation
translation could rely on both Monad and MonadError, using
throwError instead of fail (it has been suggested to use mzero,
with a separate MonadZero class, but MonadError may well
be the better match).

perhaps there'll come a time when the monadic aspects of 
haskell will need redesign, similar to the numeric aspects.

thanks! this emphasized view of MonadError might help.
claus