While you're hacking around on parsec a nice improvement would be to relax the type on the language generators in Text.ParserCombinators.Parsec.Language. (This one could be done without so drastic a change as bumping from 3 to 4):
They can all be instantiated for Monad m => GenLanguageDef String s m instead of LanguageDef, this would greatly extend their usability.
You could even go a little farther and relax them so they can work over Bytestrings, etc.
I for one always feel a little twinge when I'm forced to copy and paste them and change the signature just because I'm working in a parser that provides state, uses _any_ base monad, or consumes some other Char source.
-Edward Kmett
On Fri, Jan 28, 2011 at 8:57 AM, Christian Maeder
<Christian.Maeder@dfki.de> wrote:
Am 27.01.2011 07:16, schrieb Kazu Yamamoto (山本和彦):
> Hello,
>
> I'm using parsec3 with the applicative style. Since the functions in
> Control.Applicative and parsec3 conflicts, I need to use the "hiding"
> keyword as follows:
>
> import Control.Applicative hiding (many,optional,(<|>))
> import Text.Parsec
>
> This is inconvenient for me. I would like to use them as follows:
>
> import Control.Applicative
> import Text.Parsec
>
> Christian, the maintainer of parsec3, told me that it is possible to
> use the functions of Control.Applicative in parsec3 instead of
> implementing its own functions. But (<|>) of parsec3 is "infixr 1"
> while that of Control.Applicative is "infixl 3". This may be an
> issue.
>
> Any ideas to solve this issue?
If parsec is not changed I could create a parsec4 package where the
conflicting functions are removed from Text.Parsec.
This will break code that uses "optional" from Text.Parsec. Is there a
need for a renaming of Text.Parsec.Combinator.optional, like "voidOptional"?
Such a function would be better placed inside Control.Applicative though:
voidOptional v = const () <$> v <|> pure ()
or
voidOptional = void . optional
using the new Control.Monad.void.
C.