Support ghc-9.14

[erikd]

Needs a bump in the base dependency:

diff --git a/parsec.cabal b/parsec.cabal
index bada24c..92e050e 100644
--- a/parsec.cabal
+++ b/parsec.cabal
@@ -79,7 +79,7 @@ library
     Text.ParserCombinators.Parsec.Token
 
   build-depends:
-      base        >=4.12.0.0 && <4.22
+      base        >=4.12.0.0 && <4.23
     , bytestring  >=0.10.8.2 && <0.13
     , mtl         >=2.2.2    && <2.4
     , text        >=1.2.3.0  && <1.3  || >=2.0 && <2.2

Happy to provide a PR if you would like.

[jonathanknowles]

@phadej Please can you publish a revision for this package on Hackage that supports GHC 9.14? Many thanks. 🙏🏻

[ysangkok]

Since parsec is a boot library, I think it will have the appropriate bumps on your local machine, and should not usually need reinstallation.

EDIT: For example, you can see that parsec is available in the global package database using

$ ghc-pkg-9.14.1 field parsec depends
depends: base-4.22.0.0-66f8 bytestring-0.12.2.0-f1bc mtl-2.3.1-77f5
         text-2.1.3-075e

even though the cabal bounds would prohibit this version of base.

[jonathanknowles]

@ysangkok

Many thanks for raising the point about parsec being a boot library. You're right that the installed library is compiled against base-4.22.0.0.

However, despite this, the base < 4.22 bound (on Hackage) still seems to cause dependency resolution failures for downstream packages in practice. Two examples that fail without --allow-newer=parsec:base on GHC 9.14.1:

• Example package does not build with GHC 9.14.1. martijnbastiaan/doctest-parallel#105
• Package does not build with GHC version 9.14.1. jonathanknowles/taiwan-id#3

Do you know if there's a good reason not to update the Hackage version bounds for parsec-3.1.18.0?

[ysangkok]

Do you know if there's a good reason not to update the Hackage version bounds for parsec-3.1.18.0?

It makes sense to make sure cabal allows reinstallation for boot packages. But it might be that bounds for other packages are too strict if reinstallation is triggered. I generally think packages should work with boot packages if possible.

[jonathanknowles]

It makes sense to make sure cabal allows reinstallation for boot packages. But it might be that bounds for other packages are too strict if reinstallation is triggered. I generally think packages should work with boot packages if possible.

Thanks again for responding.

My understanding is that a metadata revision to the existing parsec-3.1.18.0 package on Hackage to correct the declared base bound to < 4.23 would be sufficient to accurately reflect the fact that GHC 9.14.1 already ships parsec-3.1.18.0 compiled against base-4.22.0.0. This would unblock the cabal solver for downstream packages that transitively depend on parsec, allowing them to use the existing boot parsec package that's already installed, without requiring re-installation. Does this match with your intuition?

If the above makes sense, then wouldn't it also be a good idea for us to try and update this repository so that it's consistent with what's distributed with GHC and published on Hackage?

I see that @bgamari already provided a PR to update the bounds for base nearly a year ago: #193.

From looking at the repository, it looks like we'd also need to update the tested-with stanza in the .cabal file and regenerate the CI configuration (which uses haskell-ci).

I'd be very happy to create a revised PR if that would help, but I'm a bit reluctant to do so before checking. Given that the existing PR is nearly a year old with no active comments, is there anyone actively maintaining this repository who would be willing to review and merge such a PR?

Thanks again!

[ysangkok]

Yes, that matches my intuition. It might make sense to ping @haskell/core-libraries-committee

[noughtmare]

FYI parsec is surprisingly not a core library

[jonathanknowles]

I've opened PR #199 to add support for GHC 9.14.1. It:

• Bumps the upper bound on base to < 4.23 (preserving @bgamari's original commit: 9533533);
• Bumps the list of GHC versions in tested-with;
• Regenerates CI using the latest version of haskell-ci.

I've tested (successfully) the CI updates on a fork here: https://github.com/jonathanknowles/parsec/actions/runs/26814866678.

[jonathanknowles]

I've made a Hackage metadata revision request here:

• Metadata revision request: parsec-3.1.18.0: bump base upper bound for GHC 9.14.1 compatibility. haskell-infra/hackage-trustees#431