- ghc-devs - Haskell.org

AArch64/Darwin CI troubles
by Ben Gamari 16 Mar '24

16 Mar '24

Hi all, It has come to my attention that all of our AArch64/Darwin CI runners are currently inexplicably unavailable. I have made some inqueries but until this is resolved I'm afraid CI will be rather stuck. I'll keep the list updated as I learn more. Cheers, - Ben

4 4

[ANNOUNCE] GHC 9.10.1-alpha1 is now available
by Ben Gamari 15 Mar '24

15 Mar '24

The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha1 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * Extension of LinearTypes to allow linear `let` and `where` bindings ([linear-let]) * The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context [exception backtrace] * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes 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]. Many will notice that this release comes a fair bit later than the previously-announced schedule. While this delay has been attributable to a variety factors, the most recent cause is a set of issues with GHC 9.10's binary distributions on Windows (#24542). Instead of continuing to hold up the release process while we sort out this situation, we have instead provided this alpha without the usual assortment of Windows binary distributions. We expect to have this resolved by alpha 2; apologies to eager Windows testers for this delay. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, 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. Happy compiling, ~ Ben [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha1/docs/users_guide/9.10.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624

2 2

Template Haskell stability
by Iavor Diatchki 11 Mar '24

11 Mar '24

Hello, I am not sure if this is the right list to post to, but I suspect template-haskell is mostly modified by GHC folk, which is why I chose to post here, and there is no maintainer listed, based just the `libraries` list. Template Haskell is a very useful tool, but I am always quite wary of using it, because it is so unstable. I understand the need to change the syntax, as the language evolves, but I feel that changes are made without any consideration for backward compatibility, which is very unfortunate. To give you an example, I am currently using GHC 9.6.4, and I am working on a small TH utility. I need to make a tuple expression, but of a dynamic size, so I can't use the special syntax, and need to use a function to do so. So I am using the function, `tupE`, which has the following type: tupE :: Quote m => [m Exp] -> m Exp This is quite nice and unsurprising. When I look oh `hackage`, however, the type of this function has changed, now it is: tupE :: Quote m => [m (Maybe Exp)] -> m Expr So what do I do? Basically I should not use this function, because as soon as I upgrade the compiler everything will break! Furthermore there is no documentation at all to explain what this function is supposed to do (I can't fathom why it is taking `Maybe` as arguments), or when it changed, etc. So my plea would be---change the syntax at will, but let's try to keep the convenience functions that build the syntax stable: instead of changing functions, it is just as easy to add a new function. I understand that sometimes things need to change, but then we should describe what changed, and in which versions. I don't think these are hard things to do, and I really think it will have great benefit to everyone using TH. Cheers, -Iavor

6 8

Upcoming GHC 9.6.5 release
by Zubin Duggal 06 Mar '24

06 Mar '24

Hello all, We are currently in the process of preparing the 9.6.5 release, which we plan to release before the end of the month. If you would like any patches to be considered for inclusion into this release, please ensure that the corresponding MRs are marked with the ~"backport needed:9.6" label. Requests for any submodule updates should be made on the release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24501 Cheers, Zubin

2 2

GHC 9.10.1 alpha 1 delay
by Ben Gamari 01 Mar '24

01 Mar '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 26 Feb '24

26 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 22 Feb '24

22 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