Haskell Platform decision: time to bless parsec 3?

[Isaac Dupree]

On 11/08/10 07:51, Christian Maeder wrote:
> I still favor parsec 2 over parsec 3 because
>
> a) parsec 3 is no longer haskell98 (as major parts of parsec 2 are)

I can't find my notes (might've disappeared in a system crash), but I 
went through all the HP packages, and I think each of the extensions 
that parsec 3 uses was used in some place in some other Platform 
package(s) too (even after excluding obviously nonportable things like 
template-haskell and the GHC-specific part of 'array').  And not all of 
parsec 2 is haskell98 (its cabal file mentions ExistentialQuantification 
and PolymorphicComponents).  In addition to parsec 2's extensions, 
parsec 3 uses MultiParamTypeClasses, FlexibleInstances, 
FlexibleContexts, DeriveDataTypeable.  I guess the first three of those 
are pretty tame (?) (or at least they seem to be used in miscellaneous 
places..).  And DeriveDataTypeable is used by extensible-exceptions, 
which is a rather central library (whether you get it from 'base' or 
'extensible-exceptions', either way).

> I think the maintainers of "parsec 3" should create new package
> "parsec3" without the compatibility layer. A new package parsec2 was
> already created.

That's an idea/vision that I think hasn't been brought up before (I 
might have forgot), in all our discussions of Parsec -- to make new 
names for both parsec2 and parsec3, and drop the compatibility layer in 
parsec3. (AFAIK there's rarely a reason to share parser data-types 
widely between modules / in interfaces, which in other cases makes a 
major benefit for having compatibility-layers and not just two separate 
library versions.)

-Isaac