New ticket 1274 -- Add a MonadState instance for the Parsec monad

Maxime Henrion mux at
Sat Apr 14 15:57:02 EDT 2007

Isaac Dupree wrote:
> Hash: SHA1
> Maxime Henrion wrote:
> > I just submitted a ticket (#1274) to add a MonadState instance for the
> > GenParser monad of Parsec.  As said in the ticket, the only drawback I
> > see to this is the added dependency on mtl.  I don't believe this is a
> > real issue though.  Of course, comments are welcome.
> Control.Monad.State.Class
> non-portable (multi-param classes, functional dependencies)
> class (Monad m) => MonadState s m | m -> s
> <>
> According to
> <>,
> only GHC and Hugs supports fundeps presently, and there would be no
> avoiding this extension if the instance were put in the module where
> GenParser is defined. -whereas Parsec has been careful to keep its
> non-Haskell98 components in separate modules that don't need to be
> imported: "If you use the ParsecToken or ParsecPerm modules, you need to
> enable the forall extension."
> <>
> Is this a correct interpretation, that this would prevent using Parsec
> with other compilers (e.g. nhc98)?

I think you are right and my patch would probably have this unwanted
side-effect.  I have underestimated the problems that arise if we
add a dependency on the mtl package.

It would be nice if it was possible to conditionally include this
code, depending on whether the compiler supports FDs and MPTCs.  I
guess it would be doable using the -cpp flag of GHC and using #if's,
but then again, maybe other compilers don't have this feature?  I
didn't check but it seems unlikely that this would be part of

I'll have to do some research to see if there are any other ways
we could deal with this issue, and I'm all ears if people have
suggestions on this.  As a side note, we're going to need MPTCs and
FDs if the SoC task of having a GenParserT monad transformer succeeds,
so this definitely needs some thinking.


More information about the Libraries mailing list