
On Sun, Dec 11, 2011 at 10:10 AM, Brandon Allbery
On Sun, Dec 11, 2011 at 10:44, Antoine Latter
wrote: On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery
wrote: On Sat, Dec 10, 2011 at 18:25, Peter Simons
wrote: src/Parsers.hs:163:52: Couldn't match expected type `Char' against inferred type `[Char]'
xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x.
It's not clear to me from reading the sources and type signatures of 'notFollowedBy' why this is different in parsec 2 vs. parsec 3.
It's not necessarily going to be visible in individual combinators, as I understand it; the issue is that Parsec2 can really only handle fundamental types such as Char, whereas Parsec3 can handle more complex types. xmobar appears to be making use of this so its higher level parsing is at the string instead of the character level, factoring out lower level issues to a lower parsing "layer".
All of the imports in the ./src/Parsers.hs are from the Text.ParserCombinators.Parsec.* module space, which was intended to be a compatibility layer, and all of the parsers and parser-combinators in ./ser/Parsers.hs appear to be written using the 'Parser' type synonym, also from the compatibility layer, which has the same token type in both parsec-2.x and parsec-3.x. So after digging deeper I'm even more curious :-)
It's not going to be something easily retrofitted into Parsec2, in any case; Parsec3 needed a fair amount of work to do it to begin with, and even more to make it do so efficiently, which is why Parsec2 remained the default in the 6.12/6.14 days.
-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms