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