August 2025 - ghc-devs

CStub in inline-java
by Facundo Domínguez 18 Sep '25

18 Sep '25

Dear devs, I upgraded inline-java [1] to use GHC 9.10.2 recently. inline-java has a GHC plugin responsible for embedding JVM bytecode in Haskell modules. This message is to consult on the most appropriate way to do it. The byte code is placed in a C literal array of bytes, and the C code is added in mg_foreign together with C constructor functions that run when loading the module to add the bytecode to a global bytecode table [2]. The global bytecode table is then fed to the JVM when initializing inline-java. The GHC API in 9.10.2 requires creating a CStub which does have a field to indicate constructor functions [3], but I wouldn't know how to create the CLabels it needs. So instead, I just put the constructor functions in the getCStub field, and set getInitializers to an empty list. The constructor functions seem to run at initialization just the same. Should inline-java do this differently? Thanks in advance! Facundo [1] https://github.com/tweag/inline-java [2] https://github.com/tweag/inline-java/blob/c6b590c29ef9190164dec3a235b8e386c… [3] https://gitlab.haskell.org/ghc/ghc/-/blob/3c37d30b07fc85fe09452f4ce250aec42… data CStub = CStub { getCStub :: SDoc , getInitializers :: [CLabel] -- ^ Initializers to be run at startup -- See Note [Initializers and finalizers in Cmm] in -- "GHC.Cmm.InitFini". , getFinalizers :: [CLabel] -- ^ Finalizers to be run at shutdown } -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

1 1

Gitlab down?
by Simon Peyton Jones 01 Sep '25

01 Sep '25

Friends Is https://gitlab.haskell.org/ down? I'm getting this, which leaves me rather stalled. Thanks Simon HTTP 502: Waiting for GitLab to boot

6 6

Is master broken?
by Oleg Grenrus 27 Aug '25

27 Aug '25

My build fails Configuring ghci-9.15... Error: [Cabal-8010] Encountered missing or private dependencies: ghc-internal >=9.1001.0 && <=9.1500.0 `ghci.cabal` indeed has ghc-internal >= 9.1001.0 && <=9.1500.0, and `ghc-internal.cabal` has version: 9.1500.0 So what is happening? My invocation is ./hadrian/build --build-root=_build_wip --flavour=default+no_profiled_libs+omit_pragmas

1 1

Documenting and improving cmm regular update
by Diego Antonio Rosario Palomino 26 Aug '25

26 Aug '25

Hello. from now on, i would like to provide regular updates about my project: documenting and improving cmm. In the past few days, i have: 1. implemented the bones for a cmm ast serialization https://github.com/GunpowderGuy/cmm-documentation/blob/master/myproject/src… 2. improved the writing / redaction on the cmm documentation i wrote that goes over how features are implemented https://github.com/GunpowderGuy/cmm-documentation/blob/master/Exploded_view… To elaborate on those points: in that document, i want to explain for each feature: * how textual cmm code gets parsed (what parser code handles an example feature) * what part of the ast (haskell data type) handles that feature * what part of the pretty printer handles the ast feature about the cmm ast (de)serializer: i have been deriving generic for the cmm datatypes, and the aeson typeclasses for said types. i started doing so with the top level type the cmm parser outputs. when implementing fromjson, ghc complains about its subtypes not implementing fromjson. i implement fromjson for those. this has been going well, but now i hit a blocker. some of the types use type level features such as gadts, which prevent generic from being derived for them. there are many ways i could work around this. generic is used for automatically deriving serialization in aeson. i could implement the methods manually for gadts types and the like, but i would prefer not doing so since going the generic way allows me to easily add more (de)serialization formats. for example, i can use a non aeson framework with fewer dependencies and the instances will be derived from generic. i could support that and conditionally not use aeson. given that, i think i could manually write generic instances or use a workaround like this: ( https://hackage.haskell.org/package/kind-generics )

1 0

Mail migration status
by Ben Gamari 26 Aug '25

26 Aug '25

Hi all, Yesterday I completed the last task of the OpenCape migration, moving our mail services from our previous, ancient Rackspace box to their new home. This was a fairly invasive process, requiring migrating to a new Mailman version and a completely new delivery configuration. As with any migration, there is a chance that something isn't quite right. If you notice any delivery or reception issues of mailing list traffic from haskell.org please do let me know. Cheers, - Ben

1 0

gitlab
by Simon Peyton Jones 26 Aug '25

26 Aug '25

Gitlab seems to have gone offline again. Does anyone know what is going on? Simon

1 0

GitLab status
by Ben Gamari 22 Aug '25

22 Aug '25

Hi all, Last night GitLab went down due to an out-of-memory condition. I have brought it back up and have modified the system configuration to hopefully avoid such situations in the future. Cheers, - Ben

1 0

Type variable scope in typed Template Haskell splices?
by Viktor Dukhovni 21 Aug '25

21 Aug '25

With the code below my signature as "Splice.hs", three nearly identical splices are defined: `good1`, `good2` and `bad`. They differ in how conversion of Int to/from Word is orchestrated around a call to the typed splice `go` whose underlying type is: Code m (Unsigned a -> Unsigned a) In the "good" variants, either the input conversion (a -> Unsigned a) or the output conversion (Unsigned a -> a) is done via a class method of `IntLike a`, the converse conversion just uses `fromIntegral`. In the "bad" variant, both use `fromIntegral`. The module compiles, but there are type inference isssues when attempting to use `bad` as a splice, that don't occur with either of the "bad" variants. Is this to be expected? $ ghci -v0 -XTemplateHaskell Splice.hs λ> :t good1 good1 :: (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> :t good2 good2 :: (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> :t bad bad :: (IntLike a, IntLike (Unsigned a), Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> f :: Word -> Word; f = $$(good1 42) λ> g :: Word -> Word; g = $$(good2 42) λ> h :: Word -> Word; h = $$(bad 42) <interactive>:6:26: error: [GHC-39999] • Ambiguous type variable ‘a0’ arising from a use of ‘meth’ prevents the constraint ‘(WordLike a0)’ from being solved. Relevant bindings include w_a2MX :: a0 (bound at <interactive>:6:26) Probable fix: use a type annotation to specify what ‘a0’ should be. Potentially matching instances: instance WordLike Int -- Defined at Splice.hs:7:10 instance WordLike Word -- Defined at Splice.hs:6:10 • In the expression: meth (fromIntegral 42) w_a2MX In the first argument of ‘($)’, namely ‘(\ w_a2MX -> meth (fromIntegral 42) w_a2MX)’ In the second argument of ‘($)’, namely ‘((\ w_a2MX -> meth (fromIntegral 42) w_a2MX) $ fromIntegral i_a2MW)’ Why does the `bad` splice fail to capture the full context of the `go` method, which one might expect to restrict the `fromIntegral` instance to be either `a -> Unsigned a` or `Unsigned a -> a` just like the `a2w` and `w2a` methods? It seems that despite "ScopedTypeVariables" and the explicit type signature go :: Code m (Unsigned a -> Unsigned a) the $$(go) splice is not tied to the same `a` as one might naïvely expect. I can write: bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] and though that compiles, runs and produces correct results, it elicits warnings: Splice.hs:30:20: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ Splice.hs:30:64: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ Splice.hs:30:77: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ In a benchmark module with a somewhat fancier splice of the "bad" sort, the use-site only compiles if both the "ScopedTypeVariables" and "TypeApplications" extensions are enabled at that the use-site, and the warnings are still produced when compiling the module that defines the splice. -- Viktor. 🇺🇦 Слава Україні! {-# LANGUAGE ScopedTypeVariables , TemplateHaskellQuotes, TypeFamilies #-} module Splice(good1, good2, bad) where import Language.Haskell.TH.Syntax class (Integral a) => WordLike a where meth :: a -> a -> a instance WordLike Word where meth = (+) instance WordLike Int where meth = (+) class (WordLike (Unsigned a), WordLike a) => IntLike a where type Unsigned a w2a :: Unsigned a -> a a2w :: a -> Unsigned a instance IntLike Word where { type Unsigned _ = Word; w2a = id; a2w = id } instance IntLike Int where { type Unsigned _ = Word; w2a = fromIntegral; a2w = fromIntegral } good1 :: forall a m. (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) good1 i = [|| \i -> w2a $ $$(go) $ fromIntegral i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||] good2 :: forall a m. (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) good2 i = [|| \i -> fromIntegral $ $$(go) $ a2w i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||] bad :: forall a m. (IntLike a, IntLike (Unsigned a), Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) bad i = [|| \i -> fromIntegral $ $$(go) $ fromIntegral i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||]

2 1

GHC 9.14.1-alpha1 is now available
by Ben Gamari 19 Aug '25

19 Aug '25

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The SPECIALISE pragma now allows use of type application syntax * The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of newtypes * the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope. * Significant improvements in the GHCi debugger * Record fields can be defined to be non-linear when LinearTypes is enabled. * RequiredTypeArgments can now be used in more contexts * SSE/AVX spport in the x86 native code generator backend * A major update of the Windows toolchain * ... and many more A full accounting of changes can be found in the release notes [1]. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have only two alphas prior to the release candidate, in contrast to the scheduled three. We expect the next alpha will come the seek of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025. We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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. [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-alpha1 [release notes]: https://downloads.haskell.org/ghc/9.14.1-alpha1/docs/users_guide/9.14.1-not… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new

1 1

GHC 9.10.3-rc4 is now available
by Zubin Duggal 18 Aug '25

18 Aug '25

The GHC developers are very pleased to announce the availability of the fourth release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. A full accounting of these fixes 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][]. The changes from the third release candidate are: - A fix for a rare segfault with code involving STM (#26205) - A fix for the `naturalAndNot` returning bogus results (#26205) - A fix for a crash in the renamer (#25056) This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 1 September 2025. We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.3-rc4 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0