Re: parsec-3 problem

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. Christian Am 18.02.2011 14:01, schrieb Edward Kmett:

On Fri, Feb 18, 2011 at 7:27 AM, Christian Maeder mailto:Christian.Maeder@dfki.de> 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries