parsec-3 problem

[Derek Elkins]

On Fri, Feb 18, 2011 at 11:13 AM, Antoine Latter <aslatter at gmail.com> wrote:
> On Fri, Feb 18, 2011 at 9:43 AM, Christian Maeder
> <Christian.Maeder at dfki.de> 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.