parsec-3 problem

Christian Maeder Christian.Maeder at
Fri Feb 18 16:43:01 CET 2011

I'm only unhappy about the compatibility layer that now turns out to be
not 100% compatible. Therefore I've created a light-weight parsec1
because parsec-3 is overkill for many cases.

It seems that I have to rename the modules in parsec1 to avoid
overlapping module names with parsec-3, unless parsec-3 drops
the compatibility layer (as I have done in parsec3) before it goes into
the platform, because dropping it later is much more difficult.


Am 18.02.2011 14:01, schrieb Edward Kmett:
> On Fri, Feb 18, 2011 at 7:27 AM, Christian Maeder
> <Christian.Maeder at <mailto:Christian.Maeder at>> wrote:
>     Hi,
>     the following code goes through parsec-2 (and parsec1) but is rejected
>     by parsec-3
>      import Text.ParserCombinators.Parsec
>      gqrrel = many1 (alphaNum <|> char '_')
>      myparser = sepBy gqrrel (char ',')
> With top level type annotations, it compiles just fine. These
> annotations are considered a best practice, their absence is even
> complained about with -Wall, and the extra utility of parsec-3 far
> outweighs their cost, IMHO.
> gqrrel :: Parser String
> gqrrel = many1 (alphaNum <|> char '_')
> myparser :: Parser [String]
> myparser = sepBy gqrrel (char ',')
> The problem is that the Stream class is an MPTC deliberately crafted
> without a fundep between the stream type and the monad in question. Any
> fix is likely to be worse than the disease, since to make type inference
> work for all scenarios that it works in Parsec-2, you'd need the fundeps
> for the stream class to be able to infer the other 2 arguments given any
> one of them. You'd lose the stream instances for lists, bytestring, etc.
> that work for all monads rather than just Identity.
> I still remain enthusiastic about the prospect of including parsec-3 in
> the platform.
> -Edward Kmett
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list