GHC 9.8.1 is now available

The GHC developers are very pleased to announce the availability of the final release of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at

GHC 9.8 brings a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations TypeAbstractions.

  • Support for the ExtendedLiterals extension, providing syntax for non-word-sized numeric literals in the surface language extended-literals

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma warnings

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors unsatisfiable

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas deprecated-exports

  • The addition of build semaphore support for parallel compilation; with coming support in cabal-install this will allow better use of parallelism in multi-package builds jsem

  • More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. Plans for GHC’s future releases can be found on the GHC Wiki.

We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.


It’s fantastic that I can see this message, fire up ghcup tui, and immediately install GHC 9.8! Thanks so much to everyone involved in the workflow that makes this possible. It means I was already able to update product-profunctors to 9.8.


@bgamari and @wz1000 have been taking over maintenance of the GHC metadata portion in ghcup, taking a lot of work off my plate.

While we’re still looking for contributors that can help with a strict review workflow, I’m happy this has been working fairly smoothly so far.


Yes! It’s incredible.

Not too long ago, each time a new GHC was released I recall idly clicking around a directory of tarballs hosted on, double-checking my architecture before firing off a download, wondering where to put the binary and what to name it…

I eventually wrote an awful bash script I used to somewhat maintain before ghcup came along and did everything better.


I have updated Stack’s default setup-info dictionary for these binary distributions, and added GHC 9.8.1’s global hints to global-hints.yaml.


I specified text: 2.1 (a number) instead of text: '2.1' (a string) - causing Stack to complain vigorously (see Stack issue #6284). This should now be fixed. Sorry to anyone inconvenienced.

When using Stack 2.13.1 with resolver: ghc-9.8.1, Stack will warn that it has not been tested with GHC 9.8 and above, and it may also warn that it failed to decode module interfaces. The latter is because the format of GHC’s *.hi files changed after GHC 9.6.3. Those warnings can be ignored, and will be fixed in the next version of Stack.


@mpilgrem Image is also available now. I have created a pull request to update Stack’s Dev Containers.
:information_source: HLS has been updated to version in Stack’s default Dev Container.

Cross reference: Haskell Language Server is now available


Nice set of new features!

Ben, I see that you link to the proposals. Is that the best user-facing source of more information? I’d have expected that these features come with sections in the user’s guide, and that that would be the more suitable description for end users (and also more accurate, in case the implementation ended up a bit different than in the proposal).


My CIs haven’t picked it up yet, despite being configured to use latest via the Haskell setup action. Is it because 9.8 is added to ghcup-vanilla, but not yet the main ghcup metadata?

9.8.1 is in the default channel already Add GHC 9.8.1 · haskell/ghcup-metadata@43f4782 · GitHub

I think the reason is that the haskell action duplicates ghcup efforts:

My suggestion is to just use plain ghcup in your CI. Example is here.

1 Like

Ah, yes, it worked a bit later. I thought I deleted my post, but looks like I misclicked. All well, thanks!

1 Like

In the master branch version of Stack:

  • the *.hi file warnings are fixed. Thanks to @hsyl20, who makes the necessary changes to the hi-file-parser package, on which Stack depends; and
  • Stack users now have the ability to mute the ‘Stack not tested on latest GHC/Cabal version’ warnings, if those messages are unwanted - see, for example, Configuration (project and global) - The Haskell Tool Stack . The messages irk some users.

In respect of ‘Stack not tested’ messages, they are updated in Stack’s code when sufficient experience of new GHC/Cabal (the library) versions is accumulated. The hurdle is low, but experience tends not to be accumulated until Stackage moves its nightly snapshot on to the GHC version in question.

In respect of obtaining the master branch version of Stack:

  • Stack can build Stack from source, with stack upgrade --source-only --git - see upgrade command - The Haskell Tool Stack ;
  • also, each time Stack’s CI is triggered and passes, it creates binary distributions for Stack. They are available as artefacts produced by the integration tests GitHub Action at Stack’s repository;
  • however, be aware that using Stack to manage Stack can conflict with using GHCup to manage Stack. That is because GHCup creates a ‘shim’ executable named stack on the PATH which calls Stack (proper). stack upgrade will likely overwrite GHCup’s ‘shim’ executable with the Stack executable (proper).

In respect of ‘released’ versions of Stack:

  • I aim to release them on a quaterly rhythym (if the changes since the last release merit a release); I don’t want to ‘spam’ the community with Stack releases; but
  • if somebody makes the case at Stack’s repository that a new ‘released’ version is needed more urgently than that, it is possible to release a new version of Stack outside of that rhythm.

Using ghc 9.8.1 with cabal latest ( gives a warning:

Warning: Unknown/unsupported 'ghc' version detected (Cabal supports
'ghc' version < 9.8): /home/peter/.ghcup/bin/ghc is version 9.8.1

The release notes for GHC 9.8.1 state that GHC 9.8 only works with cabal-install >= but the most recent version of that package on Hackage is cabal-install-

1 Like

The tl;dr is that cabal had planned a release but the release pipeline had (and still has) some issues which are delaying the release. GHC eventually shipped with a tagged but not released version of Cabal and Cabal-syntax.

TBH I find this statement a bit confusing.

  1. GHC does not depend on cabal-install; so it obviously work also for cabal-install == 0
  2. A statement on whether or not cabal-install fully support a GHC version would be more appropriate to cabal-install’s release notes.
1 Like

That sounds like GHC and Cabal need better coordination.

@bgamari @Kleidukos


I cannot find this statement in the release notes. The only reference to cabal versions is in the 2.1.11 section talking about the package database coming with the release.

Despite of the warning, cabal does seem to work with ghc 9.8.1.

Additionally, if cabal-install is rebuilt with ghc 9.8.1 as below:

cabal install cabal-install --allow-newer

even the warning disappear and the new cabal seems to work fine, at least for me so far. This build uses sources from Hackage only.

Edit: I sent my reply above by email two days ago but it never landed here for some reason.

Here: GHC 9.8.1 download — The Glasgow Haskell Compiler

I can confirm that the warning disappears if cabal-install- is rebuilt with GHC 9.8.1.

1 Like

Would it be possible to update the version history gitlab page?

So that people can see that 9.8 ships with deepseq-1.5 and text-2.1.