On Sun, Dec 11, 2011 at 10:44, Antoine Latter <aslatter@gmail.com> wrote:
On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery <allbery.b@gmail.com> wrote:
> On Sat, Dec 10, 2011 at 18:25, Peter Simons <simons@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".

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