parsec3 vs parsec-3.x

[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?

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.