Bug in Parsec.Token
dons at galois.com
Thu Mar 4 17:39:41 EST 2010
> 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?
More information about the Libraries