July 2025 - ghc-devs - Haskell.org

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

Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)
by Diego Antonio Rosario Palomino 10 Aug '25

10 Aug '25

>Hi Diego, >In the future it would make things easier if you could use one of the >common email quoting conventions (i.e. starting lines with >). It is >otherwise a bit hard to distinguish your replies from the questions >you are responding to. I am sorry, Ben Gamari. I am not used to working in mailing lists. I also messed up the formatting in my last reply. I accidentally created a second topic (but this comment uses the original topic). Please tell me if this comment uses an appropriate format so I can proceed to answer the rest of your reply. Btw, some months back my first topic on this mailing list just linked to the corresponding Discourse post: https://discourse.haskell.org/t/gsoc-2025-documenting-and-improving-cmm/118… Would it be acceptable to use Discourse for my next topic regarding this project? (Maybe with a link here, on this mailing list.) Diego Antonio Rosario Palomino

2 3

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4
by Simon Peyton Jones 31 Jul '25

31 Jul '25

Dear GHC devs This mr !10479 seems Utterly Broken. Looks as if something is wrong with CI. Can anyone help? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479 Thanks Simon On Wed, 30 Jul 2025 at 09:05, GitLab <gitlab(a)gitlab.haskell.org> wrote: > [image: GitLab] > [image: ✖] Pipeline #113076 has failed! > > Project Glasgow Haskell Compiler <https://gitlab.haskell.org/ghc> / GHC > <https://gitlab.haskell.org/ghc/ghc> > Branch > wip/T23109 <https://gitlab.haskell.org/ghc/ghc/-/commits/wip/T23109> > Commit > a90f83d4 > <https://gitlab.haskell.org/ghc/ghc/-/commit/a90f83d44ae1ad0eee63f24ff62568e…> > in !10479 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479> > Fix mergo bugs > Commit Author > Simon Peyton Jones <https://gitlab.haskell.org/simonpj> > > Pipeline #113076 <https://gitlab.haskell.org/ghc/ghc/-/pipelines/113076> > triggered by Simon Peyton Jones <https://gitlab.haskell.org/simonpj> > had 7 failed jobs > Failed jobs > [image: ✖] tool-lint lint-submods > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241378> > [image: ✖] tool-lint lint-linters > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241373> > [image: ✖] tool-lint typecheck-testsuite > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241374> > [image: ✖] packaging project-version > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241326> > [image: ✖] tool-lint lint-testsuite > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241375> > [image: ✖] tool-lint ghc-linters > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241376> > [image: ✖] tool-lint lint-author > <https://gitlab.haskell.org/ghc/ghc/-/jobs/2241377> > [image: GitLab] > You're receiving this email because of your account on gitlab.haskell.org. > Manage all notifications > <https://gitlab.haskell.org/-/profile/notifications> · Help > <https://gitlab.haskell.org/help> >

2 4

GHC 9.10.3-rc1 is now available
by Zubin Duggal 30 Jul '25

30 Jul '25

The GHC developers are very pleased to announce the availability of the 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][]. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 11 August 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-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

Fwd: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)
by Diego Antonio Rosario Palomino 28 Jul '25

28 Jul '25

---------- Forwarded message --------- De: Diego Antonio Rosario Palomino <diegorosario2013(a)gmail.com> Date: lun, 28 jul 2025 a la(s) 12:56 p.m. Subject: Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output) To: Hécate <hecate(a)glitchbra.in> Hello all, Thank you for the thoughtful responses so far, and thank you Simon for summarizing Andreas's comments. *"Do you have any use-cases in mind? Suppose you were 100% successful — would anyone use it?"* Yes — my mentor, *Csaba Hruska*, would. He's currently working on a custom STG optimizer that uses experimental techniques to enable whole-program optimizations for Haskell code. The intended pipeline is: *GHC STG → custom optimizer → textual Cmm → code generation* However, the current *parseable* Cmm is not sufficient for his use case, because it *cannot represent everything the Cmm AST can express*. Beyond this specific use case, achieving *roundtrip serializability* for Cmm could make it a *viable alternative to LLVM* for Haskell projects. Native code generation via Cmm is much faster than through LLVM. And while outputting LLVM from Cmm currently produces *less performant* code than directly targetting LLVM, I believe the inefficiencies could be fixed relatively easily. Enabling such improvements is part of the motivation for my documentation work — to help developers understand and work with Cmm and its infrastructure. *"You need a compelling reason to change the input language (understood by the parser) since libraries may include .cmm files, which will break. (It'd be interesting to audit Hackage to see how many libraries do include such .cmm files.)"* To clarify, this proposal would *not* break backwards compatibility. There are two implementation paths: 1. Introduce a *second parser* that accepts a syntax 100% identical to the pretty printer output. 2. Extend the *current parser* by adding a mode (or block) that uses a distinct keyword (e.g., low_level_unwrapped) to indicate: "expect exact syntax, no convenience fills." In either case, existing .cmm files would continue to be supported as-is. The current parser wouldn't need features removed or changed — the new syntax would *only add capabilities*. *"It’s unclear from your example how those blocks would work exactly. Is low_level_unwrapped a label? If so can we goto it? Is it a keyword? Something else entirely?"* — Andreas Apologies for the confusion — I’m not well-versed in the formal terminology. To clarify: low_level_unwrapped (or very_low_level, or another name) would be a *keyword or syntactic construct* that tells the parser to interpret the contents of the block { ... } using a syntax *identical to what the pretty printer emits*. For example: function1 { } // existing low-level syntax function2() { } // existing high-level syntax very_low_level { ... } // new mode: code with exact pretty-printed syntax inside the block *"Rather than change the language understood by the parser, would it not be easier to change the language spat out by the pretty-printer to be compatible with the parser?"* Unfortunately, that’s not a practical path forward. At the start of the project, Csaba (my mentor) recommended leaving the parser mostly untouched and focusing instead on extending the pretty printer. However, we’ve realized that the differences between the parser and the pretty printer are not trivial. The parser — even in its current “low-level” mode — *inserts inferred data* via convenience functions. It *abstracts part of the structure*, meaning we cannot fully recover the original Cmm ADT just by parsing. In other words, *modifying the pretty printer to match the parser would require it to lose information* — which I strongly oppose. If Cmm is generated programmatically, the pretty-printed version would lack structural information present in the internal data structure. And parseable Cmm would still be *incapable of expressing all features of the AST*. I hope that also addresses your concern, Hécate. This GSoC project runs until *November 10th*. I was granted extra time since, unlike most participants, I’m not working through summer vacation — I’m in the Southern Hemisphere. (Also, I realize I previously used the wrong project name in this thread — the correct title of my GSoC project is *“Documenting and improving Cmm.”*) Regarding the risk of *bitrot* in a new parser or new syntax mode: one possible mitigation would be to add *regression tests* that check whether parsing a file and pretty-printing it results in compatible output. On a related note, I’ve noticed that *some Cmm examples in the documentation and even in source code comments are incorrect or outdated*. Part of my work includes identifying and correcting these inconsistencies. Thanks again to everyone for your time and input — I greatly appreciate the discussion and feedback. Best regards, *Diego Antonio Rosario Palomino* GSoC 2025 – Documenting and improving Cmm El lun, 28 jul 2025 a la(s) 11:04 a.m., Hécate via ghc-devs ( ghc-devs(a)haskell.org) escribió: > Hi Diego, > > Thank you very much for your work in this direction, it's sorely needed. > > I'm all for having proper roundtrip correctness for Cmm, but I am not sure > altering the parser is the way to go. > In my opinion, GHC should produce valid textual Cmm, that can be ingested > by the parser at it is today. > > Have a nice day, > Hécate > Le 28/07/2025 à 02:16, Diego Antonio Rosario Palomino a écrit : > > Hello GHC devs, > > I'm currently working on Cmm documentation and tooling improvements as > part of my Google Summer of Code project. One of my core goals is to make > Cmm roundtrip serializable. > > Right now, the in-memory Cmm data structure—generated programmatically > (e.g., from STG via GHC)—can be pretty-printed, and Cmm can also be parsed. > However, the pretty-printed version is not compatible with the parser. That > is, we cannot take the output of the pretty printer and feed it directly > back into the parser. > > Example: > > Parseable version: > > sum { > cr: > bits64 x; > x = R1 + R2; > R1 = x; > jump %ENTRY_CODE(Sp(0))[R1]; > } > > Pretty-printed version: > > sum() { // [] > { info_tbls: [] > stack_info: arg_space: 8 > } > {offset > cf: // global > _ce::I64 = R1 + R2; > R1 = _ce::I64; > call (I64[Sp + 0 * 8])(R1) args: 8, res: 0, upd: 8; > } > } > > Another example: > > Parseable version: > > simple_sum_4 { // [R2, R1] > cr: // global > bits64 _cq; > _cq = R2; > bits64 _cp; > _cp = R1; > R1 = _cq + _cp; > jump (bits64[Sp])[R1]; > } > > Pretty-printed version: > > simple_sum_4() { // [] > { info_tbls: [] > stack_info: arg_space: 8 > } > {offset > cs: // global > _cq::I64 = R2; > _cr::I64 = R1; > R1 = _cq::I64 + _cr::I64; > call (I64[Sp])(R1) args: 8, res: 0, upd: 8; > } > } > > While it’s possible to write parseable Cmm that resembles the > pretty-printed version (and hence the internal ADT), they don’t fully > match—mainly because the parser inserts inferred fields using convenience > functions. > > Proposal: > > To make roundtrip serialization possible, I propose supporting a new > syntax that matches the pretty printer output exactly. > > There are a couple of design options: > > 1. > > Create a separate parser that accepts the pretty-printed syntax. Files > could then use either the current parser or the new strict one. > 2. > > Extend the current parser with a dedicated block syntax like: > > low_level_unwrapped { > ... > } > > This second option is the one my mentor recommends, as it may better > reflect GHC developers' preferences. In this mode, the parser would not > insert any inferred data and would expect the input to match the > pretty-printed form exactly. > > This would enable a true roundtrip: > > - > > Compile Haskell to Cmm (in-memory AST) > - > > Pretty-print and write it to disk (wrapped in low_level_unwrapped { > ... }) > - > > Later read it back using the parser and continue with codegen > > Optional future direction: > > As a side note: currently the parser has both a “high-level” and a > “low-level” mode. The low-level mode resembles the AST more closely but > still inserts some inferred data. > > If we introduce this new “exact” low-level form, it's possible the > existing low-level mode could become redundant. We might then have: > > - > > High-level syntax > - > > New low-level (exact) > - > > And possibly deprecate the current low-level variant > > I’d be interested in your thoughts on whether that direction makes sense. > > Serialization libraries? > > One technically possible—but likely unacceptable—alternative would be to > derive serialization via a library like aeson. That would enable > serializing and deserializing the Cmm AST directly. However, I understand > that aeson adds a large dependency footprint, and likely wouldn't be > suitable for inclusion in GHC. > > Final question: > > Lastly—I’ve heard that parts of the Cmm pipeline may currently be under > refactoring. If that’s the case, could you point me to which parts (parser, > pretty printer, internal representation, etc.) are being modified? I’d like > to align my efforts accordingly and avoid conflicts. > > Thanks very much for your time and input! I'm happy to iterate on this > based on your feedback. > > Best regards, > Diego Antonio Rosario Palomino > GSoC 2025 – Cmm Documentation & Tooling > > _______________________________________________ > ghc-devs mailing listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 2

Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)
by Diego Antonio Rosario Palomino 28 Jul '25

28 Jul '25

Hello GHC devs, I'm currently working on Cmm documentation and tooling improvements as part of my Google Summer of Code project. One of my core goals is to make Cmm roundtrip serializable. Right now, the in-memory Cmm data structure—generated programmatically (e.g., from STG via GHC)—can be pretty-printed, and Cmm can also be parsed. However, the pretty-printed version is not compatible with the parser. That is, we cannot take the output of the pretty printer and feed it directly back into the parser. Example: Parseable version: sum { cr: bits64 x; x = R1 + R2; R1 = x; jump %ENTRY_CODE(Sp(0))[R1]; } Pretty-printed version: sum() { // [] { info_tbls: [] stack_info: arg_space: 8 } {offset cf: // global _ce::I64 = R1 + R2; R1 = _ce::I64; call (I64[Sp + 0 * 8])(R1) args: 8, res: 0, upd: 8; } } Another example: Parseable version: simple_sum_4 { // [R2, R1] cr: // global bits64 _cq; _cq = R2; bits64 _cp; _cp = R1; R1 = _cq + _cp; jump (bits64[Sp])[R1]; } Pretty-printed version: simple_sum_4() { // [] { info_tbls: [] stack_info: arg_space: 8 } {offset cs: // global _cq::I64 = R2; _cr::I64 = R1; R1 = _cq::I64 + _cr::I64; call (I64[Sp])(R1) args: 8, res: 0, upd: 8; } } While it’s possible to write parseable Cmm that resembles the pretty-printed version (and hence the internal ADT), they don’t fully match—mainly because the parser inserts inferred fields using convenience functions. Proposal: To make roundtrip serialization possible, I propose supporting a new syntax that matches the pretty printer output exactly. There are a couple of design options: 1. Create a separate parser that accepts the pretty-printed syntax. Files could then use either the current parser or the new strict one. 2. Extend the current parser with a dedicated block syntax like: low_level_unwrapped { ... } This second option is the one my mentor recommends, as it may better reflect GHC developers' preferences. In this mode, the parser would not insert any inferred data and would expect the input to match the pretty-printed form exactly. This would enable a true roundtrip: - Compile Haskell to Cmm (in-memory AST) - Pretty-print and write it to disk (wrapped in low_level_unwrapped { ... }) - Later read it back using the parser and continue with codegen Optional future direction: As a side note: currently the parser has both a “high-level” and a “low-level” mode. The low-level mode resembles the AST more closely but still inserts some inferred data. If we introduce this new “exact” low-level form, it's possible the existing low-level mode could become redundant. We might then have: - High-level syntax - New low-level (exact) - And possibly deprecate the current low-level variant I’d be interested in your thoughts on whether that direction makes sense. Serialization libraries? One technically possible—but likely unacceptable—alternative would be to derive serialization via a library like aeson. That would enable serializing and deserializing the Cmm AST directly. However, I understand that aeson adds a large dependency footprint, and likely wouldn't be suitable for inclusion in GHC. Final question: Lastly—I’ve heard that parts of the Cmm pipeline may currently be under refactoring. If that’s the case, could you point me to which parts (parser, pretty printer, internal representation, etc.) are being modified? I’d like to align my efforts accordingly and avoid conflicts. Thanks very much for your time and input! I'm happy to iterate on this based on your feedback. Best regards, Diego Antonio Rosario Palomino GSoC 2025 – Cmm Documentation & Tooling

4 3

Correct parsers for bounded integral values
by Stefan Klinger 22 Jul '25

22 Jul '25

Hello, I'd like to bring to your attention a discussion that I have started over at Haskell-cafe [1]. I was complaining about the silent overflow of parsers for bounded integers: > read "298" :: Word8 42 I find this unsatisfying, and I have demonstrated a solution [2] that seems correct and performant. To avoid cross posting, I'd rather point you to the discussion on the Haskell-cafe mailing list [1]. I would like to help get this into GHC and also other parsing libraries. Not all libraries suffer from this issue, but some do, including GHC and its `base` package. How can I attempt this? Should I file a bug report? Or try to follow the instructions at ghc.dev [3] and submit a pull request? I would start tinkering at [this point][4] as soon as I manage to compile GHC. Would you want to share any advice beforehand? I'd really appreciate to be stopped before wasting effort ;-) Also, I probably only can work on this on weekends. Cheers Stefan [1]: https://mail.haskell.org/pipermail/haskell-cafe/2025-July/137134.html [2]: https://github.com/s5k6/robust-int [3]: https://ghc.dev/ [4]: https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Inte… -- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB.

5 6

GHC 9.14.1 release status
by Ben Gamari 22 Jul '25

22 Jul '25

Hi all, Last week GHC 9.14 officially forked. Over the past week I have been working to get the branch into a releasable state. Unfortunately, there are currently issues with the Windows release target that which are preventing preparation of the first alpha. I hope to have this resolved by the end of this week, allowing our first pre-release in the middle of next week. Ultimately, it is not unlikely that the release schedule will slip a bit as a result of these Windows issues. We will keep the lists informed as the situation develops. Cheers, - Ben

1 0

Improving the GHC proposals process
by Matthew Pickering 18 Jul '25

18 Jul '25

Hi all, It seems to me that the general opinion is that GHC developers are reluctant to take part in the GHC proposals process. This is an unfortunate state of affairs, the proposals process should be one serving developers rather than a hindrance. Therefore I have started a discussion on the ghc-proposals issue tracker about some ways which it might be made better. https://github.com/ghc-proposals/ghc-proposals/issues/706 Please leave your thoughts there, on how you feel about the process in general or concretely about the suggestions I have made. Cheers, Matt

1 0

GHC LTS Releases
by Andreas Klebinger 15 Jul '25

15 Jul '25

I'm pleased to announce LTS plans for GHC Read all the details here: https://www.haskell.org/ghc/blog/20250702-ghc-release-schedules.html There is also a discourse thread if you have feedback: https://discourse.haskell.org/t/ghc-lts-releases-the-glasgow-haskell-compil… Best Wishes Andreas

1 0