parsec3 vs parsec-3.x

[Antoine Latter]

On Wed, Feb 2, 2011 at 2:07 AM, Christian Maeder
<Christian.Maeder at dfki.de> wrote:
> Am 01.02.2011 21:29, schrieb Roman Cheplyaka:
>> * Christian Maeder <Christian.Maeder at dfki.de> [2011-02-01 15:03:41+0100]
>>> Am 31.01.2011 22:28, schrieb Roman Cheplyaka:
>>>> From the description of parsec3 on hackage
>>>>
>>>>   [...] I do not recommend to unconditionally use parsec3 as dependency
>>>>   in cabal files of packages for hackage. But you may want to develop
>>>>   your code using this subset of parsec3 modules and finally change the
>>>>   dependency from parsec3 to parsec-3.1.1 [...]
>>>>
>>>> I got an impression that parsec3 should be used only during the
>>>> development, not in a released package. But as a developer of a package
>>>> I have pretty good understanding of what modules I'm using, and if in
>>>> doubt I can simply run "grep -r Text.ParserCombinators.Parsec ."
>>>>
>>>> Maybe it would become more clear if you elaborate on who and how exactly
>>>> might benefit from this package?
>>>
>>> I agree, parsec3 is of limited use. It only ensures a disjoint module
>>> name space with parsec2 xor parsec1 for old or more portable code.
>>
>> Please don't get me wrong, I am not claiming that it's useless, rather
>> genuinely trying to understand what problem it solves.
>>
>>> So you could have parsec2 and parsec3 code without being forced to
>>> compile your parsec-2.x sources via the compatibility layer of parsec-3.x.
>>
>> You mean using Parsec 2 and Parsec 3 interfaces in one package?
>
> No, the parsec-3.x packages contains already both interfaces, but with a
> different implementation for the Text.ParserCombinators.Parsec modules.
>

What do you mean by 'different implementation'? The parsec-3
compatibility layer simply re-exports the Text.Parsec.* functions and
types in a different module hierarchy. Maybe I missunderstood what you
mean.

I think I'm just really confused - under what scenario I would prefer
using the 'parsec3' package to the 'parsec' package.

> With parsec3 and parsec1 you'll get (at least in my eyes) a better
> (though incompatible) implementation for the
> Text.ParserCombinators.Parsec modules.
>
>> But why would anyone want to develop a package with one implementation
>> (Parsec 2) and release it depending on another implementation (Parsec 3
>> compat. layer)? (If I got you right.)
>
> I assumed parsec-3.x will be installed anyway earlier or later by some
> other packages (there by shadowing parsec-2.x) and I considered
> installing parsec3 and parsec1 (or parsec2) in addition as the greater
> disadvantage than going through parsec-3.x's compat-layer for casual
> users, who may not be able to cope with ambiguous module names (i.e. via
> .cabal files).
>
> The main problem is that the parsec-3.x package is not split up into two
> packages, which would allow to install the compatibility layer
> separately if needed.

For those interested in the history behind this - the concern at the
time was that many modules specified 'parsec' as a dependency without
an upper-bound on which version they needed. Since we didn't want
those to break, we re-exported the new modules under the old names.

That doesn't mean it's a good situation now - but I don't see the harm
in keeping the comparability layer around for a bit (other than the
complexity burden).

Antoine

>
> HTH Christian
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>