GHC 9.8.1-alpha2 is now available

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

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

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

  • Support for the ExtendedLiterals extension, providing
    more consistent support for non-word-sized numeric literals in the surface

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

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

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

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

  • The addition of build semaphore support for parallel compilation,
    allowing better use of parallelism across GHC builds

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

A full accounting of changes can be found in the release notes.
This alpha includes roughly two dozen bug-fixes relative to alpha 1.

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.

As always, do give this release a try and open a ticket if you see
anything amiss.


EDIT: It was, indeed, ‘just me’. Thanks for the responses.

I having difficulty unpacking on Windows 11 (with Long Filepaths enabled) with 7-Zip 23.01. I get (t is test integrity of archive):

&"C:\Program Files\7-Zip\7z.exe" t ghc-

7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20

Scanning the drive for archives:
1 file, 122943861 bytes (118 MiB)

Testing archive: ghc-
Path = ghc-
Type = xz
Method = LZMA2:26
Characteristics = BlockPackSize BlockUnpackSize

ERROR: Unexpected end of data : ghc-

Sub items Errors: 1

Archives with Errors: 1

Sub items Errors: 1

Can anyone here reproduce that problem? If it is not ‘just me’, I’ll raise an issue.

Interesting, can you confirm that the sha256sum of the archive is as follows:

$ sha256sum ghc-
eadf5f37adf2ed127c896035908a1b25c0a9cd8d1b2706feb9cde44d453fe911  ghc-

I am able to extract this archive.

1 Like

I also have no issues extracting the archive (sha256 matches above), with 7-Zip 23.01 on Win11

1 Like

Something is up, because I get:

(Get-FileHash ghc- -Algorithm SHA256).Hash.ToLower()

I’ll try downloading the file again …

I also fetched the indicated tarball and confirmed that it has the expected SHA. However, the CDN does make it hard to know for certain whether you are getting the same file as me.

1 Like

Thanks for the responses. Second time around I got a file with the correct SHA256 hash and it works.

I now have another problem, which appears to me likely to be a combination of what Stack does (unpack to a temporary directory with a long-ish filepath, using 7z) and a known bug in 7z.exe related to long filepaths formed by prefixing a filepath to an archive item’s filepath. The problem manifests as (with some reformatting for clarity …):

Everything is Ok

Size:       3318026240
Compressed: 324553756
[debug] Process finished in 4694ms:


[info] Extracting ghc-

[debug] Run process:

Extracted 15 files

ERROR: Cannot open output file :
  The filename, directory name, or volume label syntax is incorrect. :
... [and so on for items that have long filepaths]

The long name for ghc-9.8.0-20230809, which gets repeated three times, means the filepaths are just creeping past the 260 character count.

EDIT: I’ll add an issue to Stack’s repository. The solution, I think, is for Stack to choose a temporary directory with a shorter filepath.

Yes, this sounds like a reasonable workaround to me.

For anyone exploring GHC 9.8.1 with Stack on Windows, the long filepath wrinkle above is now fixed in the master branch version of Stack (if you are not using GHCup to manage Stack itself, stack upgrade --source-only --git).


I have a question:

  • on Hackage, text-2.0.2 has Data.Text.Array.ByteArray as a data constructor of Data.Text.Array.Array - see Data.Text.Array

  • The library Haddocks with GHC has type Array = ByteArray - see Data.Text.Array

Is the text-2.0.2 that ships with GHC different from the text-2.0.2 on Hackage?

1 Like

With a few minor patches of dependencies, and a lot of allow-newer-deps to overcome the restriction of upper bounds, I was able to build Stack with Stack on Alpine Linux 3.18 (on WSL 2) using GHC, including with --flag stack:static. My experiment is in the ghc- branch of Stack’s repository.

For me that is good news, because I think it means that, once GHC 9.8.1 is released, I can both: (a) move Stack on from GHC 9.2.7; and (b) release statically linked versions of Stack for Linux.


Yes, this is correct.

1 Like

Kind of OT but… cannot help but wonder how will GHC 10 look like