On Sun, Dec 11, 2011 at 10:10 AM, Brandon Allbery <allber...@gmail.com> wrote: > On Sun, Dec 11, 2011 at 10:44, Antoine Latter <aslat...@gmail.com> wrote: >> >> On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery <allber...@gmail.com> >> wrote: >> > On Sat, Dec 10, 2011 at 18:25, Peter Simons <sim...@cryp.to> 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 allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe