Parsec98 is kind of a cool name, actually. -- Don garious:

...

Derek, if you wouldn't mind renaming Parsec 3, I volunteer to become the maintainer of the Parsec package.

Alternatively, how do people feel about branching Parsec 2.1 as Parsec98 in Hackage? This would allow Derek to keep Parsec 3 as the "future of Parsec" and those such as myself, the ability to freeze on the Haskell98 implementation.

Thanks, Greg

On Mon, Mar 15, 2010 at 4:37 PM, Greg Fitzgerald wrote:

...

...

If the community wants to freeze on Parsec 2, then I have no problem renaming the package, otherwise I think it is both unnecessary and a waste of effort.

Reasons one might prefer Parsec 2.1: * Haskell98 implementation * Daan Leijen's whitepapers:   http://legacy.cs.uu.nl/daan/download/parsec/parsec.pdf   http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf

Reasons one might prefer Parsec 3.1: * Parametric in the input stream type (parses ByteStrings) * Monad transformer that can be stacked on arbitrary monads * More Haddock documentation

Parsec 3 is certainly useful, but there are still good, valid reasons one might prefer Parsec 2.1.

Derek, if you wouldn't mind renaming Parsec 3, I volunteer to become the maintainer of the Parsec package.

Thanks, Greg

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 started the process of moving the parsec 2.1 source to community.haskell.org but the server wouldn't recognize the public key of Windows box, and haven't had time to look into it. If someone else wants to maintain the fork, go for it. Otherwise, I can maintain a branch on github. -Greg On Thu, Apr 1, 2010 at 8:23 PM, Antoine Latter wrote:

On Mon, Mar 15, 2010 at 11:27 PM, Don Stewart wrote:

...

Parsec98 is kind of a cool name, actually.

-- Don

Back to this -

Currently, there's a problem with two versions of parsec being in use at the same time, and there is a real desire and need for the low-complexity parsec-2.1.

If we fork and put parsec-2.1 into a parsec98 package, we could then submit that for inclusion into the platform, and continue offering parsec-3 for folks that want the complexity/features.

So yes? No? Would anyone prefer that we fork parsec-3 off instead?

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

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. 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. The exception is libs that want to ship in the platform, and those are small enough in number they can be handled on a case by case basis. Antoine

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

Isaac Dupree wrote:

On 04/02/10 02:30, Greg Fitzgerald wrote:

...

...

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".

I assert that there is harm. There will be duplicate packages installed (parsec-2.1 and parsec98-2.1) with identical code. Also, we would be committing to upload any bugfix/maintenance updates to both 'branches'.

Do you wish to argue that this is an acceptable level of harm? (I would be easily susceptible to such an argument...)

I'd argue that it's acceptable, at least under this plan: * fork parsec-2.1 as parsec2-2.1 * continue to develop parsec2-* (as desired) * deprecate parsec<3 with message to switch to parsec2-* * continue parsec>=3 as parsec-* The harm is minimal because: (a) anyone who is too lazy to upgrade their .cabal can still use parsec-2.1 until it bitrots (b) anyone who is too lazy to upgrade their code to parsec>=3 can just update their .cabal to use parsec2-* if they want to avoid bitrot (c) anyone using parsec>=3 won't notice a thing. -- Live well, ~wren

Ganesh Sittampalam wrote:

The parsec98 name sounds cool, but if used, it'll last a long time I think it'll just be sowing more confusion for a future in which the origins of the name have faded into obscurity. And what if someone wants to keep it roughly as is, but bring it up to date with the latest Haskell standard? The name would be rather a barrier then.

If versions are going to be forked off, let's aim for a consistent naming scheme - parsec2, QuickCheck1, etc. Not sure how to deal with HaXml 1.13 (the other strong candidate for this kind of treatment).

+1 to the idea of doing this as a general practice, and to all the particulars raised. Just like a package broken by the new exceptions can always switch to importing old-exception for the time being, it should be similarly easy for people to remain stable on parsec, quickcheck, haxml and such for some time to come -- not even necessarily to encourage this, but simply because it makes a uniform treatment of legacy code much more manageable. --Sterl.