[Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14

[Antoine Latter]

On Sun, Dec 11, 2011 at 10:10 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Sun, Dec 11, 2011 at 10:44, Antoine Latter <aslatter at gmail.com> wrote:
>>
>> On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>> > On Sat, Dec 10, 2011 at 18:25, Peter Simons <simons at 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                                      allbery.b at gmail.com
> wandering unix systems administrator (available)     (412) 475-9364 vm/sms
>