Bug in Parsec.Token
ml at isaac.cedarswampstudios.org
Fri Apr 2 02:00:47 EDT 2010
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...
More information about the Libraries