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

Hello all, 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. Cheers, Maxime

-----BEGIN PGP SIGNED MESSAGE----- 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 http://darcs.haskell.org/packages/mtl/Control/Monad/State/Class.hs According to http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions, 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." http://www.cs.uu.nl/~daan/download/parsec/parsec.html Is this a correct interpretation, that this would prevent using Parsec with other compilers (e.g. nhc98)? Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGH/iSHgcxvIWYTTURAi5kAJ91LZoGRxEqW3vkiNpyJSB1a/OajgCcD+4m gpzr2HQ+8uUKUEq3vAgJgG4= =cRoJ -----END PGP SIGNATURE-----

Isaac Dupree wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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 http://darcs.haskell.org/packages/mtl/Control/Monad/State/Class.hs
According to http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions, 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." http://www.cs.uu.nl/~daan/download/parsec/parsec.html
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 Haskell98. 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. Cheers, Maxime

Hello Maxime, Saturday, April 14, 2007, 11:57:02 PM, you wrote:
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 Haskell98.
it's not. moreover, probably MPTC will be a part of Haskell', but not FD - there is new Associated Types extension that tends to replace it (which is available now only in GHC 6.7 in rather early form)
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.
another SoC project is to rewrite yhc/nhc type checker which will open possibility to implement mptc/fd (like any other type extensions) in nhc. but this is the long way and not guaranteed overall, if you need fd, then you are in hugs/ghc land. it's not much problem if something implemented as SoC project will work only with these two compilers (actually, most libs are only ghc-compatible, ParseC and ByteString are rare exceptions) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin wrote:
Hello Maxime,
Saturday, April 14, 2007, 11:57:02 PM, you wrote:
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 Haskell98.
it's not. moreover, probably MPTC will be a part of Haskell', but not FD - there is new Associated Types extension that tends to replace it (which is available now only in GHC 6.7 in rather early form)
Yeah, I've seen that, Associated Types look really cool. I'm currently toying with it, rewriting the MonadState class with Associated Types. I'm waiting for GHC HEAD to finish building in order to test that code. In case you're bored: http://hpaste.org/1413.
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.
another SoC project is to rewrite yhc/nhc type checker which will open possibility to implement mptc/fd (like any other type extensions) in nhc. but this is the long way and not guaranteed
overall, if you need fd, then you are in hugs/ghc land. it's not much problem if something implemented as SoC project will work only with these two compilers (actually, most libs are only ghc-compatible, ParseC and ByteString are rare exceptions)
Thanks for the information. Am I correct in interpreting this as that you are not opposed to adding the mtl dependency on Parsec? Or that you'd rather wait for mtl to be rewritten without FDs and included in the Haskell standard before we use it there? :-) Cheers, Maxime

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)?
Just to be absolutely clear: * MPTC + FunDeps are not Haskell'98, and they are not supported by nhc98. * Parsec.Token and Parsec.Perm do not use MPTC. * Parsec.Perm uses existential quantification, which although not Haskell'98 is nevertheless supported by nhc98. * Parsec.Token uses local universal quantification, which is neither Haskell'98 nor supported by nhc98. The difference between existential quantification and local universal quantification is not widely appreciated or noticed, since both involve the 'forall' keyword. Regards, Malcolm

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malcolm Wallace wrote:
Just to be absolutely clear: * Parsec.Perm uses existential quantification, which although not Haskell'98 is nevertheless supported by nhc98. * Parsec.Token uses local universal quantification, which is neither Haskell'98 nor supported by nhc98.
The difference between existential quantification and local universal quantification is not widely appreciated or noticed, since both involve the 'forall' keyword.
Thank you for the clarification! That bit of Parsec documentation was thoroughly unclear about what it meant by using forall. (now, is there some place that has up-to-date parsec documentation that could be clearer about that?) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGI1sXHgcxvIWYTTURAsqHAKC45aZuB/6EiA5ZbUSH1K0yHAi9KACg2gPY L8eJv3AkeGLCQz1plA4pELo= =QFSh -----END PGP SIGNATURE-----
participants (4)
-
Bulat Ziganshin
-
Isaac Dupree
-
Malcolm Wallace
-
Maxime Henrion