Re: parsec3 vs parsec-3.x

Am 01.02.2011 21:29, schrieb Roman Cheplyaka:

* Christian Maeder [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. 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. HTH Christian