Bug in Parsec.Token

[sterl]

Ganesh Sittampalam wrote:
> The parsec98 name sounds cool, but if used, it'll last a long time I 
> think it'll just be sowing more confusion for a future in which the 
> origins of the name have faded into obscurity. And what if someone 
> wants to keep it roughly as is, but bring it up to date with the 
> latest Haskell standard? The name would be rather a barrier then.
>
> If versions are going to be forked off, let's aim for a consistent 
> naming scheme - parsec2, QuickCheck1, etc. Not sure how to deal with 
> HaXml 1.13 (the other strong candidate for this kind of treatment).

+1 to the idea of doing this as a general practice, and to all the 
particulars raised. Just like a package broken by the new exceptions can 
always switch to importing old-exception for the time being, it should 
be similarly easy for people to remain stable on parsec, quickcheck, 
haxml and such for some time to come -- not even necessarily to 
encourage this, but simply because it makes a uniform treatment of 
legacy code much more manageable.

--Sterl.