Bug in Parsec.Token

[Greg Fitzgerald]

> 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
<ml at isaac.cedarswampstudios.org> wrote:
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>