- ghc-devs - Haskell.org

Deprecation process for GHC.Pack
by Hécate 10 May '22

10 May '22

Hello fellow devs, Just an email to signal the start of the deprecation process of GHC.Pack, with the three-releases cycle: 1. By prose (GHC 9.6) (#21541 <https://gitlab.haskell.org/ghc/ghc/-/issues/21541>) 2. By warning (GHC 9.8) (#21540 <https://gitlab.haskell.org/ghc/ghc/-/issues/21540>) 3. By error (GHC 9.10) (#21536 <https://gitlab.haskell.org/ghc/ghc/-/issues/21536>) You can read more about the whole thing here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461 Cheers, have a nice week! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD

1 0

Specialising NOINLINE functions
by Simon Peyton Jones 09 May '22

09 May '22

Dear devs At the moment the INLINEABLE pragma means "capture my right-hand side, regardless of how big it is, so that it can be type-class-specialised, including in other modules". But it *also *says "feel free to inline me". Some users (eg Gergo) want to say NOINLINE on some functions. But for these they'd still like to generate type-class-specialised versions. After all, if we aren't going to inline them, specialising is the next best thing. But we have no way to say both "specialise me" and "don't inline me", because you can't say both INLINEABLE and NOINLINE. (That would look silly.) I think we should probably just bite the bullet and add a SPECIALISABLE pragma, *orthogonal to INLINE/NOINLNE*, which say "capture my right-hand side, regardless of how big it is, so that it can be type-class-specialised, including in other modules". It behaves exactly like INLINEABLE except that you can specify it along with INLINE/NOINLINE. Any thoughts? Do you think this needs a GHC proposal? See #21036 <https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930> Simon

5 6

[ANNOUNCE] GHC 9.2.2 is not available
by Ben Gamari 06 May '22

06 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, 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. Finally, thank you to Microsoft Research, GitHub, IOHK, 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. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h…

3 5

"Modularizing GHC" paper
by Sylvain Henry 05 May '22

05 May '22

Hi GHC devs, With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones. Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/ We welcome any feedback, here or on reddit. Cheers, Sylvain

4 3

Our ambitions for GHC 9.6
by Hécate 04 May '22

04 May '22

Hi everyone, With 9.4 just around the corner, I am gathering broad ambitions for user-facing improvements that we wish to ship for GHC 9.6. At this moment, the new JavaScript and WebAssembly backends have been listed, but I'd be very interested to add more content. This document is especially for public communication regarding our activities. Since these are ambitions, it's not a hard deadline, nor does it imply dreadful consequences for the people who didn't manage to have their improvements shipped in time. I'm really excited for 9.4 and all the good stuff we're going to have in the future of GHC! Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 1

Extending call_args when specialising DFuns
by ÉRDI Gergő 02 May '22

02 May '22

Hi, In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC extends the call_args with dummy UnspecArg elements, to make it trivially fully saturated. There's a Note describing this behaviour: """ Note [Specialising DFuns] ~~~~~~~~~~~~~~~~~~~~~~~~~ DFuns have a special sort of unfolding (DFunUnfolding), and these are hard to specialise a DFunUnfolding to give another DFunUnfolding unless the DFun is fully applied (#18120). So, in the case of DFunIds we simply extend the CallKey with trailing UnspecArgs, so we'll generate a rule that completely saturates the DFun. There is an ASSERT that checks this, in the DFunUnfolding case of GHC.Core.Unfold.specUnfolding. """ (note that the reference in the second paragraph is stale; it should point to GHC.Core.Unfold.Make.specUnfolding) So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm missing something, a DFun can't have any term parameters, only type and dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't break validate, which suggests that it is hard to even exercise this code path. I'm bringing this up because on the GHC fork that I'm working on, I have the specializer do more than vanilla GHC: on my fork, specialization of higher-kinded type variables is just as useful as specializing dictionaries. With that change, I can get GHC panics when padding DFun calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is a very weak argument for this change; what I'm looking for here is a discussion on what the padding should be, in vanilla GHC, from first principles. Thanks, Gergo

2 2

GHC 9.4.1-alpha1 now available
by Ben Gamari 02 May '22

02 May '22

The GHC developers are happy to announce the availability of the first alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha1 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - ... and much more We would like to thank Microsoft Azure, GitHub, IOHK, 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 testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

Documenting primtypes, round 1: ByteArray# and Array#
by Hécate 30 Apr '22

30 Apr '22

Hi everyone, With the sunny days back in this hemisphere, so do the documentation MRs. I have two primtypes for which I'd like some help / review / interesting information: * ByteArray#: This is mostly done, you can observe the current rendered draft documentation here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8067#note_425560 Please note that the free-floating "Byte Arrays" section of documentation cannot be exported or re-exported by GHC.Exts, so we're pretty much left with what's in the types' documentation; * Array#: The ticket is here: https://gitlab.haskell.org/ghc/ghc/-/issues/21462 State of things: In terms of documentation, we have no documentation. Some stuff can be inferred from the SmallArray# haddocks but I doubt that every property / interesting usage / pitfall can be reasonable derived from putting ¬ at the beginning of the SmallArray# documentation. Now, on an unrelated note, I'm also wondering about the fate of GHC.Pack, for a number of reasons. You will find the ticket here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461. My thanks to everyone who's helped me so far, with a special mention to bodigrim and koz ross. Cheers -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

How to coordinate Haddock MR with GHC MR?
by Norman Ramsey 20 Apr '22

20 Apr '22

GHC merge request !7442 changes the GHC API in a way that requires a one-line change in `utils/haddock`. What should I do with this? I can create an MR for the Haddock people, but I don't know how to mark it as something that should be applied at exactly the same time that Haddock transitions to GHC 9.6. Please advise. Norman

2 2

Seeking RTS experts to review delimited continuations MR
by Alexis King 19 Apr '22

19 Apr '22

Hi all, I have recently opened a draft MR with my initial implementation of first-class delimited continuations in the RTS, available here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7942 The MR is not entirely finished—it still requires docs and tests, which I am gradually working on. However, barring any bugs I discover after writing those tests, I believe the implementation itself is feature-complete with respect to the proposal. Given that it is a nontrivial patch to a somewhat unloved portion of GHC, and given that there are a couple questions I have about how best to go about testing certain interactions in the first place, I figured I would reach out and see if anyone particularly familiar with the guts of the RTS would be willing to volunteer some time to give it a careful look. The good news is that the patch is not actually very large, and it changes very little existing code: the diffstats currently sit at +1,078 -48. For those interested in taking a look at the patch, I recommend starting with the Notes mentioned in the MR description. I suspect they may be a bit sparse at the moment, so please do not hesitate to ask questions; I will do my best to respond promptly. Many thanks, Alexis

3 2