Re: Bug in Parsec.Token

if more packages want Parsec 2 then it's less disruption to split off parsec 3

Luckily, there is very little disruption to split off parsec 2.1 because there's no harm in leaving old packages as "parsec < 3". The only packages that would need to change are those included in HP packages to parsec98. On the other hand, if we forked Parsec 3 and called 2.1 version 4, then it would break any packages that depend on "parsec" or "parsec >= 3". Regardless of the number of packages on hackage that depend on Parsec 2.1, I think it's more important to avoid breaking code, and to be considerate of those off hackage that just pull in the latest Parsec. Parsec 3 does its best to be backward compatible with Parsec 2, but Parsec 2 certainly doesn't do the same for Parsec 3. Therefore, I'd say forking 2.1 as parsec98 is the clear win. -Greg On Thu, Apr 1, 2010 at 11:00 PM, Isaac Dupree wrote:

On 04/02/10 00:34, Antoine Latter wrote:

...

On Thu, Apr 1, 2010 at 10:10 PM, Isaac Dupree  wrote:

...

On 04/01/10 23:39, Greg Fitzgerald wrote:

...

It sounds to me like forking Parsec 3 would cause quite a bit of pain for other packages on Hackage, but forking Parsec 2.1 to Parsec98 would be relatively painless.

I like the idea of parsec98... But wouldn't then, the .cabal file of *every* package that wished to depend on the Platform and its parsec, (a.k.a. parsec98), have to be changed?

We've already had situations where distros are in a tight spot because they only want to ship one version of the parsec package, but they want to ship packages that list a parsec<  3 dep and packages which lists a parsec>= 3 dep.

But yes, to be strictly HP compliant a package would need to update its package description.

Do more packages want to use Parsec 2 or Parsec 3?  I believe we were operating under the assumption that we would split one of the two into a separate package (either parsec3, or parsec98), with the PURPOSE being that packages' dependencies would be updated to point to the version of Parsec that they wish to use. The naive view would be, then, if more packages want Parsec 2 then it's less disruption to split off parsec 3 and change those that depend on parsec 3, but if more use parsec 3, then vice versa. But the plan for a parsec3 package also involved creating parsec-4.0; therefore I guess there is guaranteed to be disruption for parsec2-using packages.  Presumably "parsec-2.x" would not be updated with bugfixes in either case (the different package or version would instead), so it would be a VERY GOOD IDEA for everyone to update their .cabal files.  To parsec98, in this case, which I now support.

(I ignored that some packages could care less whether they use parsec2 or parsec3. Of course, that is mostly equivalent to just using parsec2... except I suppose a parsec >=2 <4 dep would be able to select parsec2 from past Platforms, as well as up-to-date parsec3 once we remove all the parsec-version-preference hacks...)

...

I don't think that HP compliance is a goal that any package should aim for - if a library or executable is popular it will get packaged in the distros.

Windows? Mac OS?

Darcs, for example, has a (perhaps naive) ambition to minimize outside-the-Platform dependencies (maybe it's to make life easier for people who start developing, or it's out of generosity/hope to see the Platform be something that is indeed broadly useful?).

Anyway, there's a reason we do Haskell-Platform.  Let's see... - It gives us 'cabal-install' easily. - It defines a 'blessed' set of packages. (Does this mean people are more likely to know/use/be familiar with these packages? Yes, 'blessed' is a funny notion. I think it was supposed to make it easier to compile old code against an older Platform, but I forget) - IIRC, it makes it easier to install some libraries on Windows without using mingw, or something like that...

-Isaac _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries