Bug in Parsec.Token

[Don Stewart]

derek.a.elkins:
> Who is going to maintain "Parsec 4"?
> 
> I'm completely against this.  If people absolutely must have exactly
> Parsec 2's implementation we can simply copy it into Parsec 3, and the
> "compatibility" layer, in that case, will simply -be- Parsec 2.  I've
> considered this as a temporary solution for the performance issues
> just so people could move to Parsec 3 dependencies, but that should
> not be necessary now, and even then I considered it a much less than
> ideal solution.
> 
> If the community wants to freeze on Parsec 2, then I have no problem
> renaming the package, otherwise I think it is both unnecessary and a
> waste of effort.
> 

The problem is the ongoing lack of confidence in Parsec 3's performance. 
The new release goes some way to addressing this, but I think this has
gone unaddressed for too long.

Can someone address the lingering concern with benchmarks against parsec 2?

-- Don