GHC 9.12.1-alpha1 is now available!

The GHC developers are very pleased to announce the availability
of the first alpha release of GHC 9.12.1. Binary distributions, source
distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

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

  • The new language extension OrPatterns allowing you to combine multiple
    pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write
    strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in
    HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to
    define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism
    flag, which improves determinism of builds a lot (though does not fully do so)
    at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • … and many more

A full accounting of changes can be found in the release notes.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki status.

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.

45 Likes

I’m excited for or-patterns. Thank you contributors!

2 Likes

Or-patterns are good, but I’m more excited by the new defaults declarations. I have some code that could well be simplified indeed. Looking forward to 9.12!

1 Like

Does GHC 9.12 work with cabal-install-3.12.1.0 or is it required to wait for cabal-install-3.14? I am asking because the 3.12 release announcement mentioned such an incompatibility.

1 Like

@janus we expect to have the next major release of cabal-install before 9.12 is released (it has not been, and the current announcement is for an alpha). That release will allow you to use packages with Custom build type — the only limitation that currently existing cabal-install’s have (as usual). If you dont rely on Custom-built packages, you can use cabal-install-3.12 (or earlier) with GHC 9.12 alpha. You’ll see a warning but otherwise it should be fine.

2 Likes

I’m actually looking forward to being able to use the multiline strings.

5 Likes

originally posted to ghc-devs@haskell.org and glasgow-haskell-users@haskell.org

It worked for me on my M2 mac but only after uninstalling and reinstalling Command Line Tools. Vanessa McHale reported a similar problem with Command Line Tools on those mailing lists also.

I got an error when I ran ./configure on my M2 mac:

checking C++ standard library flavour… actest.cpp:1:10: fatal error: ‘iostream’ file not found
1 | #include
| ^~~~~~~~~~
1 error generated.
configure: error: Failed to compile test program

Please use the pre-release of cabal-install 3.14 to go with the pre-release of GHC 9.12: GitHub - haskell/cabal: Official upstream development repository for Cabal and cabal-install

3 Likes

In principle (see below), if you want to try with Stack:

  1. Upgrade to the master branch version of Stack (can be used only if you are not using GHCup to manage versions of Stack): stack upgrade --source-only --git.

  2. A. If you are not using GHCup to manage versions of GHC, augment Stack’s default setup-info dictionary in a configuration file (needed only until Stack has fetched the compiler once). For example, on Windows:

setup-info:
  ghc:
    windows64:
      9.12.0.20241014:
        url: https://downloads.haskell.org/ghc/9.12.1-alpha1/ghc-9.12.20241014-x86_64-unknown-mingw32.tar.xz
        # Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#setup-info
  1. B. If you are using GHCup to manage versions of GHC, augment ~/.ghcup/config.yaml. For example:
url-source:
  - StackSetupURL
  - setup-info:
      ghc:
        windows:
          9.12.0.20241014:
            url: https://downloads.haskell.org/ghc/9.12.1-alpha1/ghc-9.12.20241014-x86_64-unknown-mingw32.tar.xz
            # Can be extended with SHA protections etc: see https://docs.haskellstack.org
  1. Specify the compiler in a Stack configuration file (eg stack.yaml):
compiler: ghc-9.12.0.20241014

(I say ‘in principle’ above because the type of Distribution.Simple.Utils.findPackageDesc has been changed in Cabal-3.14.0.0 and that means Stack currently falls over. I am looking into fixing that now … EDIT: That aspect should be fixed now in the master branch version of Stack.)

It looks like GHC 9.12 has changed the format of *.hi files, so a modification of hi-file-parser will be needed. EDIT: Thanks to the speedy work of @hsyl20, the master branch version of Stack now handles GHC 9.12’s *.hi files.

2 Likes

Has the GHC project changed the way that it numbers versions? It was, for example, ghc-9.10.0.20240413 but it is now ghc-9.12.20241014. The date is z in x.y.z rather than a in x.y.z.a.

EDIT: I think this change may affect adversely the parsing of *.hi files, because the version in the file starts 9122 (...0241014) and not 9120.

1 Like

You are correct, I made a mistake while preparing the release. The next alpha will have the usual versioning scheme.

3 Likes

Thanks for the clarification.

Does hadrian really need Cabal >= 3.13 to build? That is challenging without cabal-install.

2 Likes

I don’t build hadrian with cabal-install…

2 Likes

Unfortunately, yes. Cabal 3.13 grows support for profiled+dynamic binaries, which hadrian depends upon to produce profiled+dynamic binaries.

Just a daily reminder that a build system is not just a developer tool. It’s end-user facing (distributors, casual users trying to build from source, etc.).

1 Like