
On Fri, Feb 18, 2011 at 11:13 AM, Antoine Latter
On Fri, Feb 18, 2011 at 9:43 AM, Christian Maeder
wrote: I'm only unhappy about the compatibility layer that now turns out to be not 100% compatible. Therefore I've created a light-weight parsec1 because parsec-3 is overkill for many cases.
It seems that I have to rename the modules in parsec1 to avoid overlapping module names with parsec-3, unless parsec-3 drops the compatibility layer (as I have done in parsec3) before it goes into the platform, because dropping it later is much more difficult.
The compatibility layer wasn't intended to be 100% compatible. It was intended that it would be compatible enough that existing libraries on Hackage wouldn't break.
The type signature requirement is certainly a weakness - it could probably be fixed by introducing a new parser type for the compatibility layer.
I don't have my utility scripts around that found packages on Hackage which did not specify a 'parsec' upper bound, so I do not know the current count of what would break if we removed the compatibility layer.
But even if Hackage compiled cleanly with the changes, there is also the cost of causing tutorials and other references to become outdated, and the breaking of non-public code.
So to me it seems there are a few choices:
1. Improve the compatibility layer (with a cost of new types and many, uninteresting, wrappers and the cost of more maintenance)
2. Drop the compatibility layer (with the cost of updating version restrictions across Hackage and the cost of non-Hackage breakage and confusion)
3. Do nothing.
I'm leaning towards 1 & 3, but I also know that I have a fairly strong bias towards not breaking working libraries. So I may be being overly cautious.
Just to be clear, this issue was known when the compatibility layer was first made and option 3 was chosen for exactly the reasons Edward mentioned. As far as choosing option 2, this isn't a compelling reason to choose it, which is not to say there might not be other reasons to choose it.