- ghc-devs - Haskell.org

GitLab upgrade starting shortly
by Ben Gamari 08 Jun '22

08 Jun '22

Hello all, I will be starting the GitLab upgrade shortly. Expect approximately 30 minutes of downtime. Cheers, - Ben

2 5

Two-factor authentication enforced on gitlab.haskell.org
by Ben Gamari 08 Jun '22

08 Jun '22

Hi all, Due to a recent up-tick in spam activity, we have started enforcing two-factor authentication on gitlab.haskell.org. We hope that this isn't too much of a burden, but do let us know if so and we can evaluate other options. Cheers, - Ben

1 1

GitLab upgrade tonight
by Ben Gamari 07 Jun '22

07 Jun '22

Hello everyone, Tonight, around 20:00 EST, I will be performing a GitLab upgrade. As always, the downtime should be minimal (less than 30 minutes) but I will provide status updates as necessary. Cheers, - Ben

1 0

error codes in GHC
by Richard Eisenberg 02 Jun '22

02 Jun '22

Hi devs, I just wanted to call your attention to https://gitlab.haskell.org/ghc/ghc/-/issues/21684, which will add a little more bureaucracy to adding error messages in the future, but all for a good cause. Please take a look and offer any feedback! Thanks, Richard

1 0

The GHC(i)/RTS linker and Template Haskell
by Alexis King 01 Jun '22

01 Jun '22

Hi all, I’ve recently been trying to better understand how and where time is spent at compile-time when running Template Haskell splices, and one of the areas I’ve been struggling to figure out is the operation of the linker. From reading the source code, here’s a summary of what I think I’ve figured out so far: - TH splices are executed using the GHCi interpreter, though it may be internal or external (if -fexternal-interpreter is used). - Regardless of which mode is used, TH splices need their dependencies loaded into the interpreter context before they can be run. This is handled by the call to loadDecls in hscCompileCoreExpr', which in turn calls loadDependencies in GHC.Linker.Loader. - loadDependencies loads packages and modules in different ways. Package dependencies are just loaded via the appropriate built shared libraries, but modules from the current package have to be loaded a different way, via loadObjects (also in GHC.Linker.Loader). Here, however, is where I get a bit lost. GHC has two strategies for loading individual objects, which it chooses between depending on whether the current value of interpreterDynamic is True. But I don’t actually understand what interpreterDynamic means! The Haddock comment just says that it determines whether or not the “interpreter uses the Dynamic way”, but I don’t see why that matters. My understanding was that GHCi *always* requires dynamic linking, since it is, after all, loading code dynamically. Under what circumstances would interpreterDynamic ever be False? Furthermore, I don’t actually understand precisely how and why this influences the choice of loading strategy. In the case that interpreterDynamic is True, GHC appears to convert the desired dyn_o object into a shared library by calling the system linker, then loads that, which can be very slow but otherwise works. However, when interpreterDynamic is False, it loads the object directly. Both paths eventually call into “the RTS linker”, implemented in rts/Linker.c, to actually load the resulting object. I have found precious little information on what the RTS linker does, in which contexts it’s used, or how precisely it works. Note [runtime-linker-phases] at the top of Linker.c has some information, but it’s mostly a high-level description of what the code actually does rather than an explanation of its role in the bigger picture. Does anyone know of any resources they could possibly point me to that help to explain how all the pieces fit together here? I’ve spent quite a bit of time reading the code, but I’m afraid I still haven’t managed to see the forest for the trees. Thanks, Alexis

3 2

Deep Subsumption Proposal
by Matthew Pickering 31 May '22

31 May '22

Hi all, I draw everyone's attention to the Deep Subsumption Proposal. The proposal invites the community to comment on a technical solution to the issues introduced by the simplified subsumption proposal. https://github.com/ghc-proposals/ghc-proposals/pull/511 Cheers, Matt

1 0

[Haskell] [ANNOUNCE] GHC 9.2.3 released
by Zubin Duggal 27 May '22

27 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.h…

3 4

GHC.X.Hackage and GHC's release cycle
by Ben Gamari 27 May '22

27 May '22

Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

1 0

Type vs Constraint
by Simon Peyton Jones 26 May '22

26 May '22

Dear GHC devs and core libraries committee Can I draw your attention to https://gitlab.haskell.org/ghc/ghc/-/issues/21623 This ticket makes specific proposals for how to move forward on the long-standing, and increasingly painful issue of *whether or not Constraint and Type are equal in GHC's type system*. We'd love to know what you think. Please respond on the ticket. The changes affect only GHC internals, so we aren't planning a GHC proposal, but the ticket is essentially a full proposal anyway. It affects only GHC internals, but there are some users who rely on GHC internals, which is why we are seeking your opinions. Thanks Simon

1 0

9.4 branch build failure on ByteString/Internal.hs
by Shayne Fletcher 24 May '22

24 May '22

i've found for the last couple of weeks, the 9.4 branch fails to build with the following error. is this known? a fix in the works? ``` libraries/bytestring/Data/ByteString/Internal.hs:292:23: error: • Couldn't match type ‘m’ with ‘TH.Q’ ‘m’ is a rigid type variable bound by the type signature for: TH.lift :: forall (m :: * -> *). TH.Quote m => ByteString -> m TH.Exp at libraries/bytestring/Data/ByteString/Internal.hs:292:3-6 Expected type: m TH.Exp Actual type: TH.Q TH.Exp • In the expression: [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In an equation for ‘TH.lift’: TH.lift (BS ptr len) = [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In the instance declaration for ‘TH.Lift ByteString’ • Relevant bindings include lift :: ByteString -> m TH.Exp (bound at libraries/bytestring/Data/ByteString/Internal.hs:292:3) | 292 | lift (BS ptr len) = [| unsafePackLenLiteral |] | ^^^^^^^^^^^^^^^^^^^^^^^^^^... ``` -- Shayne Fletcher

1 1