March 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

GitLab Account Approval
by Matthew Wraith 31 Mar '24

31 Mar '24

Hi everyone, I’ve requested to join the gitlab instance with username wraithm Thanks!

2 1

[ANNOUNCE] GHC 9.10.1-alpha2 is now available
by Ben Gamari 29 Mar '24

29 Mar '24

The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha2 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 * 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]. 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. [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha2/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 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

GitLab planned outage
by Ben Gamari 25 Mar '24

25 Mar '24

Hi all, On Wednesday evening EST I will bring down gitlab.haskell.org for some scheduled maintenance. I expect that the outage will likely start at 19:00 EST and last for up to two hours. Cheers, - Ben

1 0

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

GitLab account approval
by Vo Minh Thu 22 Mar '24

22 Mar '24

Hi, I've signed up with the username "noteed" on gitlab.haskell.org and would like to be approved. To give you an idea of what changes I'd like to see, and possibly already hear some feedback, here are some notes I had (all about GHCi): - Add a `:version` command. This would show either the same as `ghc --version`, or the (beginning of the) first output line of GHCi, which is "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help". This seems like a very simple addition, and could help me learn to hack GHC, and would make sense for the next point. - Have a flag to make GHCi not output the string "Loaded GHCi configuration from path/to/ghci.conf". This would let the `ghci.conf` file be in complete charge of what is displayed, instead of being necessarily followed by that string. I guess it would make sense to also hide the version string (see above). - Make it possible to start/stop and observe running threads. So maybe a `:threads` (or `:set threads`, `:show threads` ?) command. Those could be user-defined, or provided by GHCi. - Have GHCi watch files for changes (or be easily notified of changes) so it reloads them automatically (à la ghcid). I guess the main difference with ghcid is that after reloading the files, there is still an interactive prompt available (and running threads should be restarted (when using `:reload` too)). - One of the running thread, instead of being user-supplied, could be a builtin feature of GHCi: the ability to listen for commands, just like the regular interactive prompt. - Have GHCi be running as a background daemon, with no text interface beside a listening thread (or more than one). (This is related to https://gitlab.haskell.org/ghc/ghc/-/issues/15461.)

2 2

Follow up: Modifying the "StgHeader" struct
by Adithya Kumar 18 Mar '24

18 Mar '24

Hey folks, I'm adding a field to "StgHeader" under a flag. ``` typedef struct { const StgInfoTable* info; #if defined(NEW_WAY) StgWord new_field; #endif #if defined(PROFILING) StgProfHeader prof; #endif } StgHeader; typedef struct { const StgInfoTable* info; #if defined(NEW_WAY) StgWord new_field; #endif #if defined(PROFILING) StgProfHeader prof; #endif StgSMPThunkHeader smp; } StgThunkHeader; ``` Follow-up changes: ================== The following are the additional changes I've made following the `PROFILING` flag: Similar to `PROF_HDR_FIELDS` macro, I've added `NEW_HDR_FIELDS` macro: ``` #if defined(NEW_WAY) #define NEW_HDR_FIELDS(w_,hdr) w_ hdr, #else #define NEW_HDR_FIELDS(w_,hdr) /* Nothing */ #endif ``` and updated the required stg code accordingly following the changes from `PROF_HDR_FIELDS`. I've also updated `GHC.Exts.Heap.ClosureTypes.closureTypeHeaderSize` accordingly. Error: ====== I'm greeted with the following error, ``` ASSERTION FAILED: file rts/StgStartup.cmm, line 100 ``` Basically, the following assert fails ``` #define CHECK_SENSIBLE_REGS() \ ASSERT(Hp != 0); \ ASSERT(HpAlloc == 0); \ ASSERT(Sp != 0); \ ASSERT(SpLim != 0); \ ASSERT(SpLim - WDS(RESERVED_STACK_WORDS) <= Sp); ``` More context for the error: =========================== Values for the correct version: ``` Hp 283468906488 HpAlloc 0 Sp 283468911440 SpLim 283468910784 SpLim - WDS(RESERVED_STACK_WORDS) 1069080 ``` Values with the changes: ``` Hp 283468906488 HpAlloc 0 Sp 7532120 SpLim 9301536 SpLim - WDS(RESERVED_STACK_WORDS) 9301368 ``` I recorded these values by calling a C print from the Cmm code. Clearly, my changes messed up a lot of things. How do I go about this now? The past 2 weeks I've only been looking at a lot of ghc code. If any more additional context is required I can provide it. Best, Adithya

2 1

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