* 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? 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.) -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often.

On Wed, Feb 2, 2011 at 2:07 AM, Christian Maeder wrote:

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.

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Feb 2, 2011 at 10:16 AM, Christian Maeder wrote:

Am 02.02.2011 16:27, schrieb Antoine Latter:

...

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 mean the two implementations: original parsec-2 code and the compatibility layer of parsec-3

...

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

In the case, where you want your old parsec-2 code to (continue to) use the original implementation and your new code to use the parsec3 implementation (in one project).

Ah! So you want two implementations of a 'parsec' style parser in a single package, then? I've never found myself wanting to do that, but I can see how you would end up with a smaller testing/upgrade overhead. Antoine