Bug in Parsec.Token

[Isaac Dupree]

On 04/02/10 00:34, Antoine Latter wrote:
> On Thu, Apr 1, 2010 at 10:10 PM, Isaac Dupree
> <ml at isaac.cedarswampstudios.org>  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