February 2024 - 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

GHC proposals not rendering
by Simon Peyton Jones 22 Mar '24

22 Mar '24

If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on the "rendered" link, namely https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-t…, Github is now displaying the .rst source, not the rendered proposal. This has started happening (consistently across other proposals) today. Does anyone know why? How can I fix this? Simon

9 18

GHC 9.10.1 alpha 1 delay
by Ben Gamari 29 Feb '24

29 Feb '24

Hi all, Unfortunately due to persistent trouble merging the last few patches destined for 9.10.1-alpha1 I will need to delay the release by a few days. As I will be away for the first two days of next week I will be delaying by one week, placing the new alpha 1 release date on 7 March 2024. Cheers, - Ben

1 0

Understanding the restrictions on instance head shapes
by Amélia Liao 26 Feb '24

26 Feb '24

Dear ghc-devs, Prompted by a toot by Conor McBride [1], I got sent on a rabbit-chase down the hole that are the restrictions on instance head shapes. Re-assembling the relevant parts, Conor's trouble arises from code of the form data Nat data CdB (p :: Nat -> *) (m :: Nat) :: * where type Shown (p :: Nat -> *) = forall n. Show (p n) instance Shown p => Shown (CdB p) where show = ... After some shallow investigation, a similar issue came up as #13267, whose fix adds a note mentioning that the "show is not a method" error pops up in the renamer, and so is a bit tricky to improve. However, even after expanding Conor's type synonyms, the type checker now complains that an instance head can not have a forall. I do understand the reasons behind forbidding 'forall's in instance heads, but I don't see a good reason to forbid instances headed by a type synonym --- the original concern, writing an instance for a constraint tuple, is (now) forbidden regardless of whether 'checkValidInstance' uses 'splitTyConApp_maybe', by the call to 'checkValidInstanceHead'. Would a patch allowing instances headed by a type synonym be welcome, or would this need to go through a proposal? I think that it would be mostly straightforward, though laborious, to implement this; Essentially, changing 'rnMethodBinds' to annotate method bindings with a set of /all possible/ method 'Name's that match what the user wrote, together with their classes, and only deciding on the actual 'Name' in 'tcMethods', where we know the actual class name for the instance head. If this work would be welcome, I'd appreciate some pointers on dealing with TTG before I write a massive pull request that wastes everyone's time. In particular, my immediate thought for storing the extra information needed is to change the type of 'cid_binds' for 'ClsInstDecl' in *'GhcRn' only*, but trying this out locally causes quite a bit of breakage. It might make more sense to add a 'MethodBind' constructor to 'HsBindLR' which is inserted by the renamer, like 'VarBind', and removed by the type checker; but this /also/ requires quite a bit of code motion. I'm happy to open an issue on GitLab if discussing possible implementation ideas would be easier over there. Of course, simply allowing instances headed by a type synonym wouldn't fix Conor's original example, since having 'forall' in an instance head would still be forbidden. It's my understanding that the reason those are forbidden is due to nasty interactions with ScopedTypeVariables, where instance forall a. C a => forall b. D a b where brings 'b' into scope in the methods' RHSes, whereas the RHS of a top-level function with the same signature would /not/ have 'b' in scope. But given that a higher-ranked type synonym would not bring the variables it quantifies over into scope /anyway/, is there a reason to forbid it then? Cheers, Amélia [1]: https://types.pl/@pigworker/111975161248256507

2 1

Modifying the "StgHeader" struct
by Adithya Kumar 25 Feb '24

25 Feb '24

Hello, I want to add a field for collecting information about the number of GCs a particular heap object survived. I've done the following to implement this: - Add a field "StgWord gc_id" to struct "StgHeader" and "StgThunkHeader" - Update "SET_HDR" macro in "ClosureMacros.h" to update the "gc_id" - Update the "closureTypeHeaderSize" function in "Heap/ClosureTypes.hs" to account for that 1 extra word. Compilation leads to a segmentation fault. The stage 2 compiler is built. But usage of it leads to a segmentation fault. Build output: ``` chmod +x inplace/bin/ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -hide-all-packages -package-env - -i -iutils/check-api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils/check-api-annotations/dist-install/build -iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -Iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -optP-include -optPutils/check-api-annotations/dist-install/build/check-api-annotations/autogen/cabal_macros.h -package-id Cabal-3.2.1.0 -package-id base-4.14.3.0 -package-id containers-0.6.5.1 -package-id directory-1.3.6.0 -package-id ghc-8.10.7.20240224 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir utils/check-api-annotations/dist-install/build -c utils/check-api-annotations/./Main.hs -o utils/check-api-annotations/dist-install/build/Main.dyn_o utils/check-api-annotations/ghc.mk:18: recipe for target 'utils/check-api-annotations/dist-install/build/Main.dyn_o' failed make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Segmentation fault (core dumped) Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 ``` Is there any other place I've missed follow-up modifications? I appreciate any help provided. Best, Adithya

4 4

Gitlab Account
by Eli F-F 24 Feb '24

24 Feb '24

Hello! I'm requesting my account be approved. I put my username down as HexTheDragon Eli F-F

2 1

[ANNOUNCE] GHC 9.8.2 is now available
by Zubin Duggal 23 Feb '24

23 Feb '24

The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_8_2.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html This release is primarily a bugfix release addressing many issues found in the 9.8 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083) * Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370) * Fixes for some memory leaks in GHCi (#24107, #24118) * Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778) * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * And many more fixes A full accounting of changes can be found in the [release notes]. 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, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, 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. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html

1 0

Diagnosing excessive memory usage / crash when compiling - 9.8.1
by Justin Bailey 21 Feb '24

21 Feb '24

Hi! I'm trying to upgrade our (large) codebase to use 9.8.1. (I'm on an M2). When building with -01, memory on the GHC process climbs until it reaches the limit of my machine (64G) and then crashes with a segfault. With -00, that does not happen. How would I go about diagnosing what's happening? Using RTS flags to limit the heap to 32G produced the same behavior, just faster. Strangely, `-v5` does not produce any more output in the console (passed via cabal's --ghc-options). Maybe I'm doing it wrong? Pointers to existing issues or documentation welcome! Thank you! Justin

5 8

Who is in charge for approve the gitlab.haskell.org registration request?
by Evan Greenup 19 Feb '24

19 Feb '24

I have successfully signed up for a <gitlab.haskell.org> account for code contribution and bug report. But when I try to login with this account, it said that my account need to be approved by administrator of this GitLab instance. How can I get in touch with this administrator. And what procedures do I need to take to get my account be approved?

2 1

git rerere considered helpful
by Norman Ramsey 18 Feb '24

18 Feb '24

Today I learned that git has a feature that will replay resolutions of conflicts you've already resolved in a previous merge or rebase. When I was working on GHC and frequently rebasing on master, I would have killed for this feature. https://git-scm.com/book/en/v2/Git-Tools-Rerere Norman

1 0