December 2023 - ghc-devs

Reinstallable - base
by Simon Peyton Jones 07 Aug '24

07 Aug '24

Dear GHC devs Given the now-agreed split between ghc-internal and base <https://github.com/haskellfoundation/tech-proposals/pull/51>, what stands in the way of a "reinstallable base"? Specifically, suppose that - GHC 9.8 comes out with base-4.9 - The CLC decides to make some change to `base`, so we get base-4.10 - Then GHC 9.10 comes out with base-4.10 I think we'd all like it if someone could use GHC 9.10 to compile a library L that depends on base-4.9 and either L doesn't work at all with base-4.10, or L's dependency bounds have not yet been adjusted to allow base-4.10. We'd like to have a version of `base`, say `base-4.9.1` that has the exact same API as `base-4.9` but works with GHC 9.10. Today, GHC 9.10 comes with a specific version of base, *and you can't change it*. The original reason for that was, I recall, that GHC knows the precise place where (say) the type Int is declared, and it'll get very confused if that data type definition moves around. But now we have `ghc-internal`, all these "things that GHC magically knows" are in `ghc-internal`, not `base`. *Hence my question: what (now) stops us making `base` behave like any other library*? That would be a big step forward, because it would mean that a newer GHC could compile old libraries against their old dependencies. (Some changes would still be difficult. If, for example, we removed Monad and replaced it with classes Mo1 and Mo2, it might be hard to simulate the old `base` with a shim. But getting 99% of the way there would still be fantastic.) Simon

15 24

Upcoming GHC 9.4.8 release
by Zubin Duggal 09 Jan '24

09 Jan '24

Hi all, We hope to prepare the 9.4.8 release in the coming weeks. This will likely be the final release in the 9.4 series. The major patches currently slated for inclusion into the 9.4.8 are: 1. A process submodule bump to 1.6.17.0 avoiding segfaults on Darwin (https://github.com/haskell/process/issues/295) 2. A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11178) 3. A fix for a packaging bug so that we can ensure all released binaries and bundled libraries are built with `-split-sections` enabled (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9492) If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.4" by **the end of this week**. Please note that we will be quite conservative with the changes we accept for this branch at this point in its lifecycle. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Thanks, Zubin

2 4

STG register mapping
by DashiellWill 18 Dec '23

18 Dec '23

Hi all, I'm newbie at GHC, trying to read the source code and understand the design of GHC. Now I'm learning about the Haskell Execution Model, but now I'm a bit confused about the STG-machine Registers. First, as shown in the GHC wiki e.g. https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/haskell-execution… , the STG-machine has some virtual registers that are mapped to real registers, such as Base, Sp, SpLim, Hp, Rn, Fn and Dn, but unfortunately the mapping logic of the STG registers is not explained in detail here. Then I tried to read the source files of various platforms in rts/include/stg/MachRegs. At first I thought they were mapped using the callee saved registers, such as aarch64, ppc, loongarch64 and riscv64 platforms, but this seems broken on s390x and x86_64 platforms. so now I have two questions: 1. What determines the amounts of Rn, Fn and Dn for different platforms? As for Rn, aarch64 has 6 registers, loongarch64 has 5 registers, ppc has 10 registers, and riscv64 has 7 registers. As for Fn, both aarch64 and loongarch64 have 4 registers, and both ppc and riscv64 have 6 registers. 2. What is the basic rule to assign the actual processor registers to the STG machine registers? The aarch64, loongarch64, ppc and riscv64 platforms seem to have a 'normal' mapping, while the s390x and x86_64 platforms have an 'non-normal' mapping e.g. R4~R8, F5~F6 and D5~D6 in s390x use the caller saved registers. Does this mean that the caller saved registers for passing argument can be used for mapping when the callee saved registers are insufficient? Thanks, Dashiell

2 1

How is account sign-up supposed to work?
by Tom Ellis 12 Dec '23

12 Dec '23

Hello GHC devs, It is hard for new users to understand how to get their new Gitlab accounts approved by an administrator. See, for example, these messages, both in the last ten days: * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-u… * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_… The Wiki doesn't seem to provide any guidance in the "Contributing" or "Newcomers" sections. Nor does ghc.dev. Perhaps that's understandable; GHC is not the Gitlab instance. * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc * https://ghc.dev/ So how is a new user supposed to know how to get their accounts approved? It would be nice to make the process super clear. This is a longstanding issue. Tom

3 3

Build GHC in GHC2021
by Arnaud Spiwack 11 Dec '23

11 Dec '23

Dear GHC devs, Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think it's time for the base language for GHC to be GHC2021. What do we think? PS: I don't actually know where the base language for GHC is specified. I couldn't find it with a cursory search PPS: if someone makes an MR, bonus points for clearing up hundreds of lines of now-unnecessary extension on top of files. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

5 6

"Merge-buddy" response
by Alan & Kim Zimmerman 04 Dec '23

04 Dec '23

Hi all If you recall I asked a while back for people to help me get my exact print annotation re-work stack merged. I had a number of people step up to offer their help (Brandon Allbery, Zubin Duggal, Ben Gamari and Alexandre Baldé). Of these, Brandon Allbery really stepped up to the plate. We got into a daily rhythm and have now landed 37 Merge Requests, completing my initial rework. Thank you very much. There has been further discussion of next steps at https://gitlab.haskell.org/ghc/ghc/-/issues/23447, and I will be starting on the further simplification we have discussed there. Thanks again all. Alan

1 0

Annotating instances
by Jaro Reinders 04 Dec '23

04 Dec '23

Hi GHC devs, I'm working on a GHC plugin which implements a custom instance resolution mechanism: https://github.com/noughtmare/transitive-constraint-plugin Currently, I need to place instances in a specific order in a specific file to recognize them and use them in my plugin. I think my life would be a lot easier if I could put annotations on instances. I imagine a syntax like this: data MyInstanceTypes = Refl | Trans deriving Eq class f <= g where inj :: f x -> g x instance {-# ANN instance Refl #-} f <= f where inj = id instance {-# ANN instance Trans #-} forall f g h. (f <= g, g <= h) => f <= h where inj = inj @g @h . inj @f @g Using this information I should be able to find the right instances in a more reliable way. One more thing I was thinking about is to make it possible to remove these instances from the normal resolution algorithm and only allow them to be used by my plugin. Do you think this would be easy to implement and useful? Or are there other ways to achieve this? Cheers, Jaro

3 7