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