parsec-3 problem

[Antoine Latter]

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.

Antoine

> Christian
>
> Am 18.02.2011 14:01, schrieb Edward Kmett:
>> On Fri, Feb 18, 2011 at 7:27 AM, Christian Maeder
>> <Christian.Maeder at dfki.de <mailto:Christian.Maeder at dfki.de>> wrote:
>>
>>     Hi,
>>
>>     the following code goes through parsec-2 (and parsec1) but is rejected
>>     by parsec-3
>>
>>
>>      import Text.ParserCombinators.Parsec
>>      gqrrel = many1 (alphaNum <|> char '_')
>>      myparser = sepBy gqrrel (char ',')
>>
>>
>> With top level type annotations, it compiles just fine. These
>> annotations are considered a best practice, their absence is even
>> complained about with -Wall, and the extra utility of parsec-3 far
>> outweighs their cost, IMHO.
>>
>> gqrrel :: Parser String
>> gqrrel = many1 (alphaNum <|> char '_')
>>
>> myparser :: Parser [String]
>> myparser = sepBy gqrrel (char ',')
>>
>> The problem is that the Stream class is an MPTC deliberately crafted
>> without a fundep between the stream type and the monad in question. Any
>> fix is likely to be worse than the disease, since to make type inference
>> work for all scenarios that it works in Parsec-2, you'd need the fundeps
>> for the stream class to be able to infer the other 2 arguments given any
>> one of them. You'd lose the stream instances for lists, bytestring, etc.
>> that work for all monads rather than just Identity.
>>
>> I still remain enthusiastic about the prospect of including parsec-3 in
>> the platform.
>>
>> -Edward Kmett
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>