parsec-3 problem
Edward Kmett
ekmett at gmail.com
Fri Feb 18 14:01:13 CET 2011
On Fri, Feb 18, 2011 at 7:27 AM, Christian Maeder
<Christian.Maeder at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110218/9afe4b9f/attachment.htm>
More information about the Libraries
mailing list