- ghc-devs - Haskell.org

Re: LLM policy for GHC
by Teo Camarasu 16 Jul '26

16 Jul '26

Comparisons between LLMs and calculators were made earlier in this thread. That reminded me of this paper https://arxiv.org/abs/2507.19960 which explores these sorts of comparisons. I find that it provides a helpful framework for analysing the relationship between LLMs and cognition. Cheers, Teo

4 3

LLM policy for GHC
by Simon Peyton Jones 15 Jul '26

15 Jul '26

Dear GHC developers There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting - this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi…> I would welcome constructive feedback on it. As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better. Thank you to those who have already given me some private feedback, which has made the draft much better. Simon

7 13

few minute gitlab downtime
by Magnus Viernickel 14 Jul '26

14 Jul '26

Dear GHC Devs, there will be a short gitlab downtime (few minutes) right now because I need to adjust a setting to fix an issue with the deployment. Best Magnus

1 0

More Gitlab things
by Magnus Viernickel 12 Jul '26

12 Jul '26

Hi all, A couple of heads ups: 1. the gitlab container may tell your it's booting some times again today because I'm upgrading its host. This should only take a couple of minutes at most 2. CI might be impaired since we have some issues with gitlab's docker registry 3. if you're missing some of your commits on the MR, it doesn't mean they're lost, it means they will appear later. We currently have a bunch of load on the background task queue and when we catch up your stuff will start appearing. Best Magnus

1 0

Gitlab upgrade finished!
by Magnus Viernickel 12 Jul '26

12 Jul '26

Dear GHC Devs, I'm happy to tell you that Ben and I successfully upgraded the postgres yesterday. Ben heroically pulled through with the gitlab upgrade all the way to the latest available until 7am my time! Huge thank you to the heroic work of Ben, taking the time and nerves to put up with this non-sense. It took at total of 14 hours until he was finished. Have fun with the new UI. Best Magnus

2 1

gitlab
by Magnus Viernickel 12 Jul '26

12 Jul '26

Dear GHC Devs, of course it would have been too good if everything was fine - it looks like the `ghc/ghc` repo currently does not update when pushing to it. I'm hoping to resolve this. Best Magnus

1 1

gitlab maintenance downtime starting soon
by Magnus Viernickel 11 Jul '26

11 Jul '26

Dear GHC Devs, This is your reminder that the announced GHC gitlab maintenance downtime will start soon. Best Magnus

1 0

GitLab availability update
by Magnus Viernickel 09 Jul '26

09 Jul '26

Dear GHC Devs, As you certainly noticed, the gitlab reliability started going again ca. 2 weeks ago. Already enacted changes improved the situations slightly (e.g. mitigated Anubis bypass) but not enough to make a smooth contributing experience possible. I am writing this mail to inform you about the following: 1. We will probably set most projects to `Internal`. This means that all projects where it's not important that they're publicly visible (like the main ghc/ghc repo) will be set to Internal, meaning they're only visible to logged in users. This will probably also affect your forks of GHC. 2. There will be a bigger gitlab outage this weekend Sat, 18:00 CEST (12:00 ET). We will give another go at upgrading our gitlab since that will allow us to do some prioritization of logged in users' traffic and this has been on our backlog for longer anyway. The downtime will be significant (multiple hours). During that time, you can change your upstream URL to github. The same is true for .gitmodules. 3. We will probably (if the infra team agrees) try out more aggressive defenses against bots since Anubis seems to not have the lasting effect we'd hoped. I am truly sorry this causes so much inconvenience for you and I hope we will be back to a usable state after the weekend. Best Magnus

1 0

Please don't use LLMs for my sake
by code＠jaro.addy.io 03 Jul '26

03 Jul '26

Friends, After some reflection, I feel the need to make it clear to everyone that I do not approve of LLMs (in their current state). I do not use them myself, but I also do not want the issues I open to cause others to use LLMs to help me, as seems to have been the case with #23173 (caused by me pushing for #27347). I would be delighted if we could all agree to a less laissez-faire "AI" policy in the future, but for now I simply wish to avoid inadvertently encouraging LLM use by others. Warm regards, Jaro

1 0

gitlab account trouble, and bug report
by Evan Laforge 03 Jul '26

03 Jul '26

Sorry to bother with gitlab administrivia, and please let me know if there's a better place to ask! I've been trying to file an issue at gitlab.haskell.org and having no luck. I'm pretty sure I had an account, and the browser remembers a password, but gitlab says it's invalid. Ok, fine, so I do forgot password, and it says if I have registered email it sent a reset... but didn't (checked spam etc.). Ok maybe it doesn't think I'm registered, so I try a new account and it says my email is already taken. At that point I'm a bit stuck, aside from creating a new email address specifically for this! So I suppose I'm not quite asking for account approval, but for either delete so I can recreate, or somehow unstick the reset password notifier, if that is in fact stuck. TIA for any assistance! Alternately, maybe someone could paste in the issue for me, though of course in the longer run I'd like to be able to file my own and maybe even help out if possible. Here's my description copied from haskell-cafe. This is a regression that started with 9.4 (presumably new recompilation avoider) and persists to the present day (well, 9.12.4 at least). Note that it only manifests when ghci is loading bytecode, but also has `.o` files around to load, so in the repro it's important to restart without -fobject-code. The -fobject-code is just imitating the build system, which would have created `.o` files for up-to-date sources: % cat >BugA.hs module BugA where x :: Int x = 13 % cat >BugB.hs module BugB where import qualified BugA f :: IO () f = print BugA.x % cat >BugC.hs module BugC where import qualified BugB bug :: IO () bug = BugB.f % ghci -fobject-code # compile so we can load .o GHCi, version 9.12.4: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/elaforge/qlib/dotfiles/.ghci Prelude> :load BugC [1 of 3] Compiling BugA ( BugA.hs, BugA.o ) [2 of 3] Compiling BugB ( BugB.hs, BugB.o ) [3 of 3] Compiling BugC ( BugC.hs, BugC.o ) Ok, three modules loaded. Leaving GHCi. % ghci Prelude> :load BugC Ok, three modules loaded. Prelude BugC> bug 13 As expected! Now go edit BugA.hs, and change 13 to say 14, and save. Now reload: Prelude BugC> :r [1 of 3] Compiling BugA ( BugA.hs, interpreted ) [Source file changed] Ok, three modules reloaded. Prelude BugC> bug 13 It has the old value! It should probably have reloaded BugB and BugC as bytecode, which is what 9.2 will do. Previously modifying a parent would force the graph in between the loaded module and the modified one to be reloaded as bytecode, ignoring the object code which is otherwise up to date. I don't know why exactly, previously I assumed BugB.o has stale values from BugA.o inlined, but leaving -fobject-code on just recompiles BugC and it works fine so maybe not!

1 0